Старый программист исчез. О том, чтобы нанять другого программиста. Как мне подойти к этому? [закрыто]

Проведя более года, работая над проектом социальной сети для меня с использованием WordPress и BuddyPress , мой программист исчез, несмотря на то, что ему платили каждую неделю за весь период. Да, он не умер, так как я использовал трекер электронной почты, чтобы подтвердить и увидеть, что он открывает мои письма, но он не отвечает. Кажется, он получил другую работу. Интересно, почему он просто не мог так сказать. И я даже заплатил ему аванс за работу, которую он не сделал.

Проблема в том, что я никогда не просил полную документацию по большинству функций, которые он кодировал. И было много функций за этот период в 1+ года, и у некоторых из них есть ошибки, которые он до сих пор не исправил. Теперь все кажется запутанным.

Что я должен сделать первым? Как мне продолжить?

Я думаю, что первое, что нужно сделать, - это найти другого программиста, но я хочу начать с правильной ноги, документируя весь текущий код, чтобы любой программист мог работать со всеми функциями без проблем.

Это первое, что я должен сделать? Если да, как мне это сделать?

Какой стандартный тип документации требуется для чего-то подобного? Могу ли я найти программиста, который просто сделает документацию для всех кодов и исправит ошибки, или документация не очень важна?

Кроме того, считаете ли вы, что лучше найти другого «индивидуального» программиста или компанию, в которой работают программисты, чтобы, если программист, назначенный на мой проект, исчез, другой мог заменить его без моего участия? Я чувствую, что это подход, который я должен был использовать в начале.

Основываясь на том взаимодействии, которое у нас было в комментариях, я буду исходить из того, что вы не прогнали своего единственного разработчика из-за личных вещей. Тем не менее, основываясь на этом разговоре, я сделаю еще одно предположение, что эта неудача по-прежнему в основном является вашей обязанностью менеджера по найму. Как вы уже упоминали, у вас нет ВСЕГО опыта работы с разработчиками, но тогда как вы принимаете решение о том, как его нанять?

Похоже, вы сделали все возможное, но вы наняли кого-то, кто просто не мог справиться с масштабами этого проекта, он построил шаткую основу, которая рушилась под ним, а затем он просто ушел. К сожалению, разница между разработчиками и предпринимателями заключается в том, что первым платят почасово / оклад, но они могут выбирать приходить и уходить когда им заблагорассудится. Ему платили за часы, которые он работал, и он ушел, когда решил больше не платить. С этим ничего не поделаешь.

И что теперь? Кажется, вы начали идти по пути замены людей процессом. Если бы только у вас было достаточно документов, люди могли бы уйти, а другие могли бы забрать с того места, где они остановились. ИМО, который не работает, и если он действительно работает, он все равно будет намного дороже, чем наличие надежной команды постоянных сотрудников. Руководство в различных компаниях за последние 30 лет пыталось заменить людей достаточным количеством документации (включая мою последнюю работу), и они терпели неудачу каждый раз. Вот почему я решил сменить работу, и теперь они застряли со своими устаревшими и никогда не точными документами, в то время как у меня есть время моей жизни в новом стартапе.

Что бы я сделал на вашем месте, я бы попытался найти подходящего человека с достаточными навыками и опытом, чтобы поднять этот проект и довести его до конца. Это включает в себя не только навыки кодирования, но и дизайн, архитектуру и основы управления проектами. Не пытайтесь определить, как он выполняет свою работу или сколько документов ему нужно представить. Просто сфокусируйтесь на поиске подходящего человека и будьте готовы платить соответственно. Когда вы найдете его, убедитесь, что ваша роль состоит в том, чтобы поддерживать его и устранять препятствия на его пути, а не контролировать / микроуправлять. Я не имею в виду, что вы делали это раньше, но я знаю, что многие менеджеры, как правило, делают это, и это просто контрпродуктивно.

Поговорите с другими предпринимателями, возможно, с большим опытом разработки программного обеспечения. Прочитайте эти форумы и задайте ряд вопросов, чтобы задать свой предполагаемый найм. Представьте проблему и спросите, какой будет подход. Если он правильный парень (и при условии, что он не видел эту страницу), он должен быть в состоянии предложить многое из того, что другие люди уже предложили в отношении того, что должно быть сделано в вашей компании, когда вы начинаете восстанавливаться. Попросите его определить план с момента его найма до того, как ваш v1.0 будет поставляться. Как он тебя туда доставит. Обратитесь за помощью, интервьюируя такого человека.

Несколько моих собственных мыслей: отслеживание ошибок является обязательным (Jira стоит 10 долларов для команды из 10 человек). Контроль исходного кода является обязательным (git является бесплатным. Выполнять арахис расходов для команды до 5 человек или около того). Ваш код - это ваша документация. Не ваши письменные документы. Он должен пересмотреть код и сохранить то, что можно восстановить; выкинуть все остальное и сосредоточиться на написании поддерживаемого и читаемого кода. Сохраняйте документацию для нескольких высокоуровневых документов на несколько страниц. Он должен знать технологию, над которой вы работаете. Не нанимайте кого-то только с добрыми намерениями; Вы не можете позволить им учиться в свое время. Спросите их, какие другие проекты они сделали (к сожалению, вам или кому-то, кого вы нашли, возможно, придется не отставать от технических аспектов). Вы ищете человека с достаточным опытом, но в то же время не слишком сильным, чтобы искра возбуждения уже сгорела. Найдите человека, который хочет оказать влияние. Методология, которую он предлагает или следует, должна позволять вам видеть работу на регулярной основе (один или две недели) и обеспечивать мгновенную обратную связь. Не нанимайте НИКАКОГО, кто говорит, что он будет готов ровно через 7,4 месяца, я дам вам знать, когда это будет сделано.

Удачи

Это странная ситуация, и я уверен, что вы не рассказываете всю историю. Я работал со многими людьми, некоторые из которых уехали по разным причинам (я являюсь их коллегой), но не пытайтесь сказать нам, что все было супер хорошо, и однажды просто не контактировал.

Но это не проблема. По крайней мере, больше нет; Вы должны учиться на своей ошибке и стараться не повторять ее в будущем. И да, я настоятельно полагаю, что 50% - это ваша вина, что он ушел.

Теперь о решении текущей проблемы:

1. Попробуйте связаться с вашим программистом. Он читает вашу электронную почту - предлагайте ему деньги за документацию / исправление самых важных ошибок. Никто другой не сможет починить их быстрее, чем он. Разве это не работает? Попробуйте найти, где он работает, свяжитесь с этой компанией и расскажите свою историю. Хорошая компания не наймет человека, который мог бы сделать то же самое для них. По крайней мере, они скажут ему закончить документацию для вас.

   ПРИМЕЧАНИЕ: вы не хотите, чтобы этот человек вернулся, вам просто нужна готовая документация

2. Будьте готовы к тому, что ваш годичный труд будет недействительным. Возможно, он сбежал, когда вы попросили результаты, и он знал, что не может доставить. Вполне возможно, что код полон хаков, грязной реализации и общего низкого качества. Даже если он вернется - у него, вероятно, не будет навыков или даже времени, чтобы сделать это правильно.

3. Ищите другого человека. Ему нужно знать одни и те же технологии (язык программирования, фреймворки и т. Д.). Если качество кода хорошее - он мог бы продолжить, если нет, он сможет его реорганизовать. Да, рефакторинг требует времени без реализации новых функций, но делает код поддерживаемым, и это то, что вам нужно. Плюс, человек, который может реорганизовать плохой код, действительно хороший программист, держитесь за него / нее.

   ПРИМЕЧАНИЕ: глупо платить деньги заранее. Вся идея зарплаты заключается в том, чтобы платить за выполненную работу. Не для обещания, сделанного :)

4. Составьте списки. В ваших интересах иметь план. Однажды прочитанная техническая спецификация позволит новому программисту понять работу и основные этапы. Иметь как минимум три важных документа:

   • Общее описание проекта - документ, который позволит даже непрограммисту узнать, о чем проект.

   • Сроки - какую часть и когда вы ожидаете быть готовым? Что уже сделано?

   • Техническая спецификация - это длинная. Это документ, который программист хочет прочитать. Разделите его на логические части и опишите как можно более подробно функции и рабочий процесс этой конкретной части.

Работать с компаниями не очень хорошо; Ваши шансы не улучшатся. И вы будете переплачивать 10 раз, если нанимаете только одного программиста. Если у вас небольшая команда, скажем, 3-5 человек, просто наймите программиста, желающего стать руководителем команды. Он намного лучше справится с управлением командой.

Документирование кода впоследствии другим программистом? Это просто мой собственный опыт и мнение, что я не должен идти по этому пути.

Без более детального знания качества этой кодовой базы, я считаю, что ваш лучший подход - нанять нового программиста для исправления ошибок, обслуживания и, возможно, внесения необходимых изменений.

Это мнение имеет ключевую точку возможных изменений (изменение или добавление), поскольку они должны быть выполнены требование. Это означает, что какая-то спецификация требований должна быть написана. Это документ.

Что приводит к поддержанию всего проекта. Вы не указали в своем вопросе, существуют ли текущие требования к программам или даже грубая функциональная документация, но на этом вы должны сосредоточиться сейчас.

Если на данный момент у вас нет никакой документации, вам нужно заполнить этот пробел. Вы не можете нанять программиста для перепроектирования вашего приложения и создания чудесной документации из этого . Вы должны «объяснить», что вы хотите, чтобы программа делала (даже если это означает, чтобы объяснить, что уже запрограммировано.)

Когда у вас будет написан этот документ (будь то в форме требований или функциональной спецификации), вы получите гораздо лучшие результаты от найма нового программиста, поскольку вы сможете передать документацию и начать работать с этого момента.

Есть также много программ, которые создают документы из исходного кода, что является хорошим способом создать скелет объяснения фактического исходного кода (это относится к области технической спецификации), с которым вы можете работать только в контексте объяснения технических аспектов функциональность указана в функциональной спецификации, которая определяет функциональность требований, указанных в спецификации.

Так что да, мое мнение заключается в том, чтобы нанять программиста для исправления ошибок. После того, как он исправит ошибки, которые вы согласились исправить, вы можете обсудить аспект документирования как другой контракт. По счастливой случайности вы наняли программиста, у которого есть некоторый опыт и который может помочь вам в следующих шагах.

Вот как я могу подойти к проблеме:

• У вас есть знание предметной области. Вы знаете, какие функции доступны на веб-сайте сейчас, какие из них вы хотели бы добавить в будущем, и, вероятно, можете также перечислить несколько ошибок, о которых сообщили пользователи.

• Там есть эта куча кода, оставленная себе в углу. Возможно, он содержит ошибки, но все равно приносит пользу, поскольку на сайте есть активные пользователи. Таким образом, полное переписывание будет ошибкой IMO.

Мост между вашей экспертизой домена и кодом был сломан, когда программист ушел. Вам нужно перестроить его так, чтобы база кода снова синхронизировалась с вашими требованиями и чтобы можно было разрабатывать будущие обновления.

Дело в том, что этот мост не может быть полностью сделан из документации. Программное обеспечение является человеческим вопросом настолько же, насколько и техническим. Если вы не объясните новому программисту, что вы ожидаете, в мельчайших подробностях, ему или ей будет трудно вывести это из одного кода - тем более, если предыдущий программист написал загадочный, плохо документированный, плохо протестированный код. И если вы не работаете в тесном сотрудничестве с новым программистом, чтобы найти автоматизированный, непрерывный способ проверки кода, соответствующего вашим требованиям, другими словами, чтобы сделать мост более устойчивым, проблема обречена на повторение.

• Регулярно садитесь (даже виртуально) с новым программистом для сеансов обработки знаний в предметной области. Во время каждой из этих сессий напишите спецификации для небольшой части вашего продукта. Это может быть одна веб-страница, это может быть функция. Создание их исполняемых спецификаций (а-ля, управляемая поведением) ) повысит уровень вашей уверенности в том, что мост работает, потому что вы можете запускать их постоянно и получать предупреждения, если что-то не так. Это также сделает жизнь разработчика проще.

  После сеанса разработчик может вернуться к своей работе и написать тесты более низкого уровня, которые подтверждают, что текущий код соответствует спецификации. Если это не соответствует, то у программиста есть все, что ему нужно, чтобы это исправить. Также важно оставаться доступным для любых вопросов, которые он мог иметь.

• Постарайтесь поддерживать тесное, постоянное сотрудничество между вами и программистами в вашем проекте, и убедитесь, что это также верно для них. Это необходимо, если вы хотите, чтобы функциональная и техническая культура вокруг вашего проекта продолжала существовать, избегая проблем, подобных той, что у вас есть сейчас. Это, конечно, требует не только 2+ разработчиков, работающих над вашим проектом, но и того, что они делятся друг с другом знаниями обо всем, что пишут. Таким образом, один может действовать как отказоустойчивый, когда другой пропадает. Такие методы, как парное программирование и анализ кода, являются хорошими способами для достижения этой цели.

Просто добавив к тому, что все сказали,

Если вы не можете заставить старого программиста документировать свой код даже по цене, тогда не ждите, что кто-то еще сможет документировать его лучше. Итак, вот несколько вариантов того, что вы можете сделать сейчас, чтобы сделать нового программиста продуктивным в первый день.

1. Получите базу данных ошибок и начните вводить в нее все найденные ошибки. Это список задач программиста. Хорошо документируйте это и вставьте как можно больше деталей (исходный файл / основная причина, что он делает и что должен делать). Существует множество бесплатных программ отслеживания ошибок, таких как Bugzilla , Redmine и JIRA . Не стесняйтесь использовать то, что вам нравится.
2. Создайте лист спецификации для вашего проекта. Это даст новому программисту определенное направление после устранения ошибок. Вы можете проверить руководство Джоэла по написанию спецификаций .
3. Создайте расписание или график для вашего проекта. У них должны быть сроки и этапы, в которых им платят за работу, которую они выполняли, вместо того, чтобы платить им заранее.

Теперь, когда это не так, вы можете начать искать программиста. И, как сказал Creative Magic, аутсорсинг работы компаниям может привести к катастрофе или взорвать цену до бесконечности и за ее пределами.

На этот раз, начните правильно планировать фактор шины при найме программистов. Люди приходят и уходят, и вы ничего не можете с этим поделать, поэтому подготовьтесь к худшему на этот раз, пригласив двух программистов, или, как сказал Ууу, один программист и один тестер.

Теперь, когда программисты находятся в магазине с вами, вы можете начать просить их задокументировать свой код, а не просить документировать старый код, действительно, забудьте об этом.

Другие вещи, которые следует учитывать при получении нового программиста, убедитесь, что они знают управление исходным кодом и автоматизированное тестирование. Кроме того, постарайтесь получить как можно больше проверок на тесте Джоэла с их помощью, вы можете сделать это только самостоятельно.

Итак, ваш единственный программист был сбит автобусом , и вам нужна замена сейчас.

Вы можете попытаться подать в суд на своего бывшего программиста, основываясь на вашем контракте, или выяснить, что с ним не так. Предполагая, что он не вернется, это вам не поможет.

• Вы хотите, чтобы ваш продукт был готов, поэтому ищите программиста, который имеет опыт в обслуживании и разработке существующих систем. Я бы не стал рассказывать вашему программисту, что делать в каком порядке. Убедитесь, что вы нанимаете кого-нибудь профессионала, который пишет документацию и модульные тесты, когда это необходимо.
• Со своей стороны вы можете убедиться, что у нового программиста есть все необходимое для его работы : требования к спецификации, мощная рабочая машина и так далее. Вам нужен профессиональный программист, поэтому предоставьте ему профессиональную рабочую среду.

Кроме того, подумайте о том, чтобы нанять второго разработчика для облегчения подобных сложных ситуаций в будущем. Тестер также будет полезен для обеспечения качества.