Як ви керуєте проектами, залишеними іншими працівниками? [зачинено]

Буває, що хтось просто покидає компанію раптом. Тепер його роботу потрібно закінчити, і ви її покладете. Не маючи поняття, що він робив (це було зроблено на 90% чи 9%), як ти керуєш залишком?

1. Почати з нуля? Що робити, якщо це було зроблено на 90%?
2. Чи повинен я спробувати і зрозуміти, що він зробив? Що робити, якщо це була просто дурниця?

Для того, щоб розібратися, що робити, вам потрібно знати, що у вас є, і наскільки він хороший.

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

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

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

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

Після цього початкового дослідження ви повинні мати приблизну оцінку

• що продукт повинен робити,
• що він може робити зараз і як добре,
• скільки часу та ризику знадобиться, щоб переписати з нуля,
• скільки часу та ризику знадобиться, щоб закінчити вже зроблене.

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

На мій досвід, це не рідкість. На жаль, у вас справді є дві проблеми :

1) Залишений проект цього проекту 2) Причини ви потрапили в цей безлад насамперед

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

У будь-якому випадку вам потрібно негайно здійснити наступні кроки:

а) Скажіть своїм менеджерам, що у вас є велика проблема

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

в) Поговоріть з менеджерами / замовниками тощо та дізнайтеся, чи хтось має / думає, що має якесь уявлення про стан проекту.

Після цього ви зможете почати вивчати код / ​​розробити стратегію.

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

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

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

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

Що стосується частини (2), можливо, вашій компанії доведеться вивчити політику найму / політику утримання персоналу, знайти способи забезпечення відповідальності програмістів за прогрес.

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

Вам обов'язково потрібно спробувати запустити програмне забезпечення, щоб побачити, що працює, а що ні.

Потім вам потрібно буде розглянути, яка документація залишилася. Чи є письмові вимоги? Чи є конкретні завдання - чи відстежуються завдання якимось чином? Хтось тестував це - якщо так, то він буде знати, що зроблено, а що ні.

Я думаю, що план дій був би таким:

1. Позначте, які вимоги були виконані (швидким пробігом системи, як тестер)

2. Подивіться на код - чи можете ви його зрозуміти? Чи добре написано?

Зрозуміло, що якщо це зроблено на 90%, і код добре записаний, ви просто закінчите його.

Ще не згадується.

Спробуйте зв’язатися з хлопцем, який вийшов. Це неможливо не у кожному випадку. Але якщо він здоровий і хоча б трішки сподобався його роботі, він допоможе і дасть вам чесну відповідь про прогрес і відсутні частини. І він міг би пояснити вам велику картину.

Вітаю, це ваш шанс блиснути і зробити по-справжньому позитивне враження на ваших начальників. Що у вас тут є безцінна можливість. Отже, що вам потрібно зробити і як?

Спочатку дістаньте код. Він, можливо, не все перевірив (хлопець, який це зробив нам, не зробив), і тому хтось із правами адміністратора витяг його з комп’ютера і перевірить це на вас.

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

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

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

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

Тепер у вас є те, що потрібно, щоб розпочати фактичне кодування, тому приступайте до роботи.

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

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

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