Старий програміст зник. Здається взяти на роботу іншого програміста. Як я підходжу до цього? [зачинено]

Провівши понад рік, працюючи над проектом соціальної мережі для мене, використовуючи WordPress та BuddyPress , мій програміст зник, хоча йому платили кожен тиждень, протягом усього періоду. Так, він не мертвий, оскільки я використовував трекер електронної пошти, щоб підтвердити і побачити, як він відкриває мої електронні листи, але він не відповідає. Здається, він влаштувався на іншу роботу. Цікаво, чому він просто не міг цього сказати. І я навіть заплатив йому авансову зарплату за роботу, яку він не робив.

Проблема полягає в тому, що я ніколи не просив повну документацію для більшості функцій, які він кодував. І було багато функцій за цей період 1+ років, і деякі з них мають помилки, які він досі не виправляв. Зараз це здається все заплутаним.

Що перше, що я повинен зробити зараз? Як мені діяти?

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

Це перше, що я повинен зробити? Якщо так, то як мені це зробити?

Який стандартний тип документації необхідний для подібного? Чи можу я отримати програміста, який буде просто робити документацію для всіх кодів та виправляти помилки, чи документація не дуже важлива?

Крім того, ви вважаєте, що краще отримати іншого "індивідуального" програміста чи отримати компанію, яка працює з ними для програмістів, так що якщо програміст, призначений для мого проекту, зникне, інший може замінити його без моєї участі? Я відчуваю, що це такий підхід, який я мав би застосувати на початку.

Виходячи з тієї взаємодії, яку ми мали у коментарях, я буду припускати, що ви не відігнали свого єдиного розробника через особисті речі. Однак, грунтуючись на цій розмові, я ще раз здогадаюся, що ця невдача все ще здебільшого є вашою відповідальністю як менеджера з найму. Як ви вже згадували, у вас В УСІМ немає жодного досвіду роботи з розробниками, але як тоді ви приймаєте рішення про те, як його найняти?

Здається, ви зробили все можливе, але ви найняли когось, хто просто не впорався з масштабом цього проекту, він побудував хиткий фундамент, який розвалився під ним, а потім він просто пішов. На жаль, різниця між розробниками та підприємцями полягає в тому, що колишнім платять щогодини / зарплату, але вони можуть вирішити приїжджати та їхати як завгодно. Йому заплатили за відпрацьовані години, і він пішов, коли вирішив більше не отримувати зарплату. З цим нічого не можна зробити.

І що тепер? Схоже, ви почали йти по шляху заміни людей процесом. Якби у вас було достатньо документації, люди могли б виїхати, а інші могли забрати місце, де вони залишилися. ІМО, який не працює, і якщо він працює, все одно буде набагато дорожчим, ніж мати надійну команду постійних працівників. Керівництво в різних компаніях протягом останніх 30 років намагалося замінити людей достатньою документацією (включаючи мою останню роботу), і вони щоразу зазнавали невдач. Тому я вирішив змінити роботу, і тепер вони застрягли зі своїми застарілими і ніколи не точними документами, в той час як я переживаю час свого життя в новому стартапі.

Що б я зробив, якби я був ти, - спробувати знайти потрібну людину з достатньою кількістю навичок та досвіду, щоб забрати цей проект і довести його до завершення. Це включає не лише навички кодування, але й дизайн, архітектуру, а також базове управління проектами. Не намагайтеся визначити, як він виконує свою роботу, чи скільки документів потрібно зробити. Просто зосередьтеся на пошуку потрібної людини та будьте готові платити відповідно. Коли ви все-таки знайдете його, переконайтеся, що ваша роль полягає у підтримці його та усуненні перешкод на його шляху, а не в моніторі / мікроконтролі. Я не маю на увазі, що ви робили це раніше, але я знаю, що багато менеджерів, як правило, роблять це, і це просто протилежне продуктивності.

Поговоріть з іншими підприємцями, можливо з тими, хто має більше інженерних програм. Прочитайте ці форуми і придумайте набір питань, щоб задати потенційну роботу. Представте проблему і запитайте, яким би був підхід. Якщо він правильний хлопець (якщо припустити, що він не бачив цієї сторінки), він повинен мати можливість запропонувати багато речей, які вже запропонували інші люди з точки зору того, що слід робити у вашій компанії, коли ви починаєте одужувати. Попросіть його визначити план від часу його найму до того, коли буде доставлено ваш v1.0. Як він тебе туди приведе. Зверніться за допомогою до інтерв'ю з такою людиною.

Лише кілька моїх власних думок: відстеження помилок - це обов’язково (Джира коштує 10 доларів для команди до 10 осіб). Контроль джерел є обов'язковим (git безкоштовний. Perforce коштує арахіс для команди до 5 осіб або більше). Ваш код - це ваша документація. Не ваші письмові документи слова. Він повинен переглянути код і зберегти те, що підлягає врятуванню; викиньте інше і зосередитесь на написанні коду, який можна читати і читати. Збережіть документацію для декількох документів на високому рівні, на декількох сторінках. Він повинен знати технологію, над якою ви працюєте. Не наймайте когось із добрими намірами; ви не можете дозволити собі, щоб вони навчалися свого часу. Запитайте їх, які інші проекти вони зробили (на жаль, вам чи комусь, кого ви знайдете, можливо, доведеться йти в ногу з технічним аспектом). Ви шукаєте когось з достатнім досвідом, але в той же час не надто, щоб ця іскра хвилювання вже вигоріла. Знайдіть когось, хто голодний, щоб зробити вплив. Запропонована ним або дотримана методологія повинна дозволяти вам регулярно (один або два тижні) бачити роботу та надавати миттєвий зворотній зв'язок. Не наймайте жодного, хто скаже, він буде готовий рівно за 7,4 місяця, я повідомляю вам, коли це буде зроблено.

Удачі

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

Але це не проблема. Принаймні більше не; вам слід вчитися на своїй помилці і намагатися не повторювати її в майбутньому. І так, я настійно висловлюю думку, що ви виправдаєтесь, що 50% вините його.

Тепер про вирішення поточної проблеми:

1. Спробуйте зв’язатися зі своїм програмістом. Він читає ваш електронний лист - запропонуйте йому гроші за документацію / виправлення найважливіших помилок. Ніхто інший не зможе виправити це швидше за нього. Це не працює? Спробуйте знайти, де він працює, зв’яжіться з цією компанією та розкажіть свою історію. Хороша компанія не найме людини, яка могла б зробити те саме для них. Принаймні, вони скажуть йому закінчити документацію для вас.

   ПРИМІТКА. Ви не бажаєте повернути цю особу, вам просто потрібна готова документація

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

3. Шукайте іншу людину. Йому потрібно знати ті самі технології (мова програмування, рамки тощо). Якщо якість коду хороша - він може продовжуватись, якщо ні, він зможе переробити його. Так, для рефакторингу потрібен час без застосування нової функції, але це робить код доступним і саме це вам потрібно. Плюс до того, що людина, яка здатна змінити поганий код, є дійсно хорошим програмістом, тримайтеся за нього / її.

   ПРИМІТКА: нерозумно платити гроші вперед. Вся ідея зарплати полягає в оплаті за виконану роботу. Не для обіцянки, зробленої :)

4. Складіть списки. У ваших інтересах - мати план. Технічна специфікація, яка прочитається, дозволить новому програмісту зрозуміти роботу та основні етапи. Майте щонайменше три важливі документи:

   • Загальний опис проекту - документ, який дозволить навіть непрограмісту знати, про що йдеться у проекті.

   • Хронологія - яка частина і коли ви очікуєте бути готовими? Що вже зроблено?

   • Технічні умови - це довгий. Це той документ, який хоче прочитати програміст. Розділіть його на логічні частини та опишіть якомога детальніше, наскільки ви зможете ознайомитись із особливостями та робочим процесом цієї конкретної частини.

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

Після цього документувати код іншим програмістом? Це лише мій власний досвід та думка, щоб сказати вам, що не слід йти таким шляхом.

Не маючи більш детальних знань про якість цієї кодової бази, я вважаю, що ваш найкращий підхід - найняти нового програміста, щоб виправити помилки, підтримувати та, можливо, вносити потрібні зміни.

Ця думка є ключовим моментом можливих змін (зміни або доповнення), оскільки вони потребують виконання вимоги. Це означає, що якась специфікація вимоги повинна бути записана. Це документ.

Що призводить до точки підтримання всього проекту. Ви не сказали у своєму питанні, чи існують поточні вимоги до програм або навіть груба функціональна документація, але саме на цьому слід зосередитися.

Якщо у вас зараз немає жодної документації, то заповнити цю порожнечу більше. Ви не можете найняти програміста, який займатиметься інженерією вашої програми та дивом формує документацію із цього . Ви повинні "пояснити", що ви хочете робити програмою (навіть якщо це означає переосмислити те, що вже було запрограмовано.)

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

Існує також багато програм, які створюють документи з вихідного коду, що є хорошим способом скласти скелет пояснення фактичного вихідного коду (це в області технічних умов), з яким ви можете працювати лише в контексті пояснення технічних аспектів функціональність, зазначена у функціональній специфікації, яка визначає функціональність вимог, визначених у специфікації вимог.

Так що так, моя думка - найняти програміста, щоб виправити помилки. Після того, як він виправить помилки, які ви погодилися, слід виправити, ви можете обговорити аспект документування як інший договір. Якщо пощастило, ви найняли програміста, який має певний досвід і може сприяти тому, які кроки слід зробити далі.

Ось як я підійшов до проблеми:

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

• Там стоїть цей стос коду, залишений собі в кутку. Це може бути баггі, але він все ще надає значення, оскільки на сайті є активні користувачі. Таким чином, повне перезапис буде помилкою ІМО.

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

Вся справа в тому, що цей міст не може бути повністю виготовлений з документації. Програмне забезпечення - це людська справа стільки, скільки і технічне. Якщо ви не поясните новому програмісту те, чого ви очікуєте дуже докладно, йому або вона буде важко визначити це лише з коду - тим більше, якщо попередній програміст написав загадковий, погано задокументований, погано перевірений код. І якщо ви не працюєте в тісній співпраці з новим програмістом, щоб знайти автоматизований, безперервний спосіб перевірити код, який відповідає вашим вимогам, інакше кажучи, щоб зробити міст більш надійним, проблема приречена повторюватися.

• Регулярно сідайте (навіть практично) з новим програмістом для сеансів обробки домену. Під час кожного з цих сеансів складіть разом специфікації для невеликої частини вашого продукту. Це може бути одна веб-сторінка, це може бути функція. Створення їх технічних характеристик (a la Behavior-Driven Development ) підвищить рівень вашої впевненості в тому, що міст працює, оскільки ви можете безперервно запускати їх і попередити, коли щось не так. Це також полегшить життя розробника.

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

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

Просто додавши до того, що всі сказали:

Якщо ви не можете змусити старого програміста документувати свій код навіть за ціною, тоді не сподівайтесь, що хтось інший зможе документувати його краще. Ось ось кілька варіантів того, що ви можете зробити зараз, щоб зробити нового програміста продуктивним в перший день.

1. Отримайте базу даних про помилки та почніть вводити в неї всі виявлені помилки. Це список пріоритетних завдань програміста. Добре задокументуйте його і введіть якомога більше деталей (вихідний файл / першопричина, що він робить, і що він повинен робити). Існує безліч безкоштовних програм для відстеження помилок, таких як Bugzilla , Redmine та JIRA . Сміливо користуйтеся тим, що вам подобається.
2. Створіть специфікаційний лист для свого проекту. Це дасть новому програмісту деякий напрямок після видалення помилок. Ви можете ознайомитися з посібником Джоела щодо написання технічних характеристик .
3. Створіть графік або часовий рядок для свого проекту. Вони повинні мати терміни та основні етапи, коли вони отримуватимуть зарплату за виконану роботу, а не сплачувати їх заздалегідь.

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

На цей раз почніть правильно планувати коефіцієнт шини, коли наймаєте програмістів. Люди приходять і йдуть, і ви нічого не можете з цим зробити, тому підготуйтеся до найгіршого цього разу, отримавши двох програмістів, або, як сказав Uooo, придбайте одного програміста і одного тестера.

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

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

Тож ваш єдиний програміст потрапив у автобус , і вам зараз потрібна заміна.

Ви можете спробувати подати до суду на свого колишнього програміста на підставі договору або дізнатися, що з ним не так. Якщо припустити, що він не повернеться, це вам не допоможе.

• Ви хочете виконати свій продукт, тому шукайте програміста, який має досвід у підтримці та розробці існуючих систем. Я б не зосереджувався на тому, щоб сказати вашому програмісту, що робити в якому порядку. Переконайтесь, що ви найняли когось із професіоналів, які пишуть документацію та тестові одиниці, коли це необхідно.
• Зі свого боку, ви можете переконатися, що новий програміст має все необхідне для своєї роботи : Технічні вимоги, потужна робоча машина тощо. Ви хочете професійного програміста, тому забезпечте йому професійне робоче середовище.

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