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

Кінцевий термін - через 1,5 місяці, і я вважаю, що б ми не робили, цей проект провалиться. Я вважаю, що ми повинні просто припинити проект і перестати витрачати свій час, але політично я вважаю, що для нашого менеджера це зробити неможливо.

Що мені робити в цьому випадку? Чи варто докладати додаткових зусиль, чи мені просто просто взяти це? І що мені сказати менеджеру?

Причини, через які цей проект є невдалим:

• Із наближенням терміну багато обов'язкові функції не закінчені
• Застосування нестабільне та дуже складне у використанні
• Система дуже складна, код дуже важкий для розуміння, дуже важко змінити - модель даних надто керована складною реляційною базою даних (100+ таблиць)
• Неясне керівництво; менеджер реагує на нову інформацію великими змінами
• Майже немає автоматизованих тестів або одиничних тестів
• Сильно залежить від інших систем, але ще немає тестів на інтеграцію

Насправді ми насправді наслідували цей проект (разом із безладом) близько 1-2 місяців тому від іншої команди розробників під тим самим менеджером, яка працювала над ним кілька місяців.

Повідомте свої проблеми найбільш стислим та неконфліктним можливим способом вгору по сходах управління. Підсумуйте ризики, але не нав'язуйте їм свій висновок.

Керівництво має завжди мати вибір, що робити, але ваша робота - оцінити та повідомити ситуацію. Використовуйте електронну пошту, щоб залишити паперовий слід, коли справи йдуть на південь.

Зробивши це, продовжуйте сумлінно працювати над проектом.

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

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

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

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

Я порекомендую вам трохи піти, щоб прочитати 2 книги.

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

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

3 прості та цинічні стратегії підтримки кар’єри / розуму.

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

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

3. Плануйте аварійний вихід на T + 1: дайте собі кілька варіантів і зробіть основу для потенційної внутрішньої чи зовнішньої передачі вже зараз. Розмовляти з людьми; немає ніяких причин чекати, коли інші вирішать, що робити з вами, коли фінансування проекту буде скорочено, або потрапляє в неминуче «тупання» людей, що переселяються через пару місяців.

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

Який вплив цей невдалий невдалий проект матиме на вашу кар’єру на фірмі та за її межами? На мій досвід, лише пов'язаність з успішними проектами не є показником вашої особистої майстерності.

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

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

Часто той самий хаос і неорганізованість, який виникає з невдалим проектом, дає вам можливість сяяти.

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

По суті, сума досвіду, запозичена невдачами, є тим, що підживлює справжній успіх.

Примітка: Томас Оуенс запитав, які конкретні речі людина може зробити в такому проекті. У мене є кілька загальних пропозицій, які я використовував як особисті вказівки в цих ситуаціях. Чи допоможе це проект, який зазнав лиха, досягти дивовижного успіху? Ні - але я виявив, що це допомогло мені дотримуватися належного погляду на речі та досягати особистого успіху, незважаючи на погану ситуацію.

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

2) Зосередьтеся на особистих показниках - скільки коду ви пишете, що породжує наступні помилки? Зменшіть цей коефіцієнт до мінімально можливого. Коли вас запитують, щоб дати оцінку завданню, яке вам призначено, чи ви загалом точні, чи ви вважаєте, що ви перевищили / перевантажили тимчасову шкалу занадто багато? Чи фактично вам призначено завдання, чи надаєте ви хороший рівень зворотного зв’язку щодо прогресу роботи, включаючи повідомлення заздалегідь заздалегідь повідомлення про проблеми із часовою шкалою доставки?

3) Зосередження уваги на командних показниках - це лише деякі моменти в голові: чи інші члени команди відстають через залежність від завдання, над яким ви працюєте? Чи добре ви делегувати або ділити своє завдання / підзадачі іншим в команді? Чи важко вам спілкуватися з одним або кількома членами команди? Усі сфери, над якими я регулярно працюю, вдосконалюються.

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

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

Крім цього, ви дійсно повинні доглядати за номером 1.

• Документуйте все
• зберігати всі електронні листи, чати
• Спробуйте знайти вихід із проекту, якщо це можливо

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

Все відносно точки зору.

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

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

Хоча ви можете робити якусь із задоволених вами робіт. У поточному проекті явно є елементи, які вам не подобаються.

Вам потрібно визначити, що це за проблемні елементи, та вирішити їх.

• термін тиску
• контроль якості
• професіоналізм
• керівництво керівництвом

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

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

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

Ви будете набагато щасливішими.

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

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

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

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

1) Робіть свою роботу. Не хвилюйтесь так багато про загальний проект, доки ви не виконаєте свої обов'язки.

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

3) Складіть кілька ввічливих пропозицій щодо вдосконалення. Не озвучуйте попереджувальних дзвіночків, не будьте приреченими і похмурими, просто будьте ввічливими і витонченими.

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

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

Також:

4) Опортуністичний рефакторинг - це ваш друг.

1. Важко працювати; але не за рахунок вашої родини чи здоров’я.
2. Вести облік всіх критичних дизайнерських рішень; особливо, коли вони стосуються вашої роботи.
3. Тримайте мережеві зв’язки та залишайте свої варіанти відкритими, якщо ситуація стає занадто складною або ви стаєте жертвою масового звільнення.
4. Постарайтеся не думати про свій проект як про "невдалий проект". Всім подобаються люди, які залишаються позитивними і важко борються перед лихом. Тому якомога довше намагайтеся бути такою людиною. Позитивний прогноз, зернистість та рішучість завжди корисні для робочого місця.
5. Якщо ви очікуєте невдалого проекту, то передчуваєте посмертну зустріч. На посмертній нараді всі будуть притягуватися до відповідальності. Будьте готові захищати весь свій код. [Примітка. Як правило, ви завжди повинні писати чистий код, щоб потім було легко його захистити.] Якщо у вас є електронний лист або дизайн-документ, який надихнув ваші рішення, то це ще краще.
6. На цій посмертній зустрічі намагайтеся залишатися позитивною; і тільки уявити свою адресу електронної пошти і дизайн документів докази , якщо ваше судження, зусилля, або майстерність ставиться під сумнів.

Що я вважав найбільш ефективним - це рекомендація Роберта Л. Прочитайте, як боротися з тиском у графіку . Ось що пише Read:

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

Ключовим розумінням того, що оцінка повинна бути зрозумілою, є те, що праця - це майже несжимальна рідина. Ви не можете більше пакувати в проміжок часу, ніж можете запакувати більше води в контейнер, що перевищує об'єм цього контейнера. У певному сенсі програміст ніколи не повинен говорити "ні", а скоріше казати "Що ти відмовиш, щоб отримати те, що ти хочеш?" Ефектом створення чітких оцінок буде підвищення поваги до програмістів. Так поводяться інші професіонали. Буде видно наполеглива робота програмістів. Встановлення нереального графіка також буде болісно очевидним для всіх. Програмістів не можна підмивати. Просити їх зробити щось нереальне - це зневажливо і деморально.

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

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

Як тільки ви обговорите цей детальний графік зі своїм менеджером, будьте готові бути гнучкими. Ваш менеджер може сказати, що "Завдання X не займе місяця; це займе не більше тижня", або "Завдання Y зовсім непотрібна, виріжте це з розкладу". Ви, звичайно, можете обговорити ці моменти, але що набагато важливіше - досягти взаєморозуміння між вами та вашим менеджером у якійсь реалістичній версії розкладу. Таким чином, якщо вам не виділяється час, скажімо, на тестування, то ви отримаєте чітку директиву не тестувати, а просто просто "несподівано" закінчитися. І, безумовно, можливо, що ваш менеджер законно готовий явно вирізати певні кути, щоб вчасно доставити - є багато випадків, коли це "

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

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

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

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

Ось деякі спостереження, які я пригадую.

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

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

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

На старшій посаді краще бути готовим виграти від невдачі «опосередковано», проаналізувавши, що пішло не так і що можна було зробити краще.

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

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

Що стосується більш практичного зауваження, можна розглядати підхід "наступний / оновлений випуск" як можливий вихід з ладу. Випадково чи ні (я думаю, що ні ), але обидва невдачі, які не пошкодили мою кар’єру, пішли за дуже схожими сценаріями: випуск Nбув тотальним лихом, випуск N+1був терпимим, випуски N+2та пізніше мали звичайний успіх.

Гуляючи у вашому взутті, я, швидше за все, доклав би певних зусиль для підготовки / просування ідеї "наступного випуску". Складіть (і спілкуйтеся !) Щось на зразок попереднього списку відомих проблем, які ви хочете виправити після запланованого виходу. Складіть неформальну, приблизну дорожню карту для наступних випусків.

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

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

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

• ^{Цілком ймовірно, що між заморожувальним кодом для запланованого випуску та рішенням керівництва повністю його скасувати буде досить тривалий час. Цей час - ваш шанс: якщо зосередити зусилля на вирішенні відомих проблем і належним чином «євангелізувати» прогрес, це може змінити ситуацію (як це колись було зроблено для мене).}

Тут уже є посилання практичних (і в іншому випадку) порад, але для мене ключовими для цієї таємниці є наступні два пункти (акцент мій):

Кінцевий термін - через 1,5 місяця

і

... ми фактично просто успадкували цей проект (разом із безладом) близько 1-2 місяців тому від іншої команди розробників під тим самим менеджером ...

Тому....

Ласкаво просимо до команди Patsy The Avengers

Попередній команді було краще робити ... ніж невдачі. І якось менеджер пішов разом із цим. Зміна команд у цей термін не є найкращим кроком для управління проектами, так що ... що з цим?

Виправлення: попередня команда була замінена, за 3 місяці до встановленого терміну.

-> Дізнайтеся, як попередній команді розробників вдалося втекти, і зробіть це. <-

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

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

Суворий? Так. Але хоча погане планування (принаймні!) Попередніх команд / менеджерів не є вашою виною, "неспроможність доставити" буде .

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

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

Отже, я (все-таки) думаю, що вас посадили.

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

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

Але завжди пам’ятайте : не приймайте поради про кар’єру від незнайомих людей в Інтернеті.

Це неймовірна можливість для вас! Давайте розглянемо підприємницьку точку зору на це.

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

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

Визнайте тут свою можливість покращити свої навички.

[1] Скасування проекту насправді матиме успіх. Невдача буде витрачати хороші гроші після поганого.

Що ти можеш зробити

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

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

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

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

Що ви не можете зробити, але ваше управління, мабуть, повинно

• Вони не повинні додавати більше людей до проекту "допомогти" побачити це

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

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

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

Що НЕ слід робити

• Попросіть додати більше людей до проекту (див. Це )

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

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

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

• Звинувачуйте людей (або себе), це ніколи не допомагає

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

Ось тільки два мої центи, YMMV

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

• Якість статичного коду можна кількісно оцінити за допомогою багатьох інструментів статичного аналізу. Ви можете зберігати це так просто і детально, як вважаєте за потрібне. Я пропоную розпочати показники:
  • Цикломатична складність
  • Розмір коду (наприклад, Nr рядків на функцію / клас, кількість файлів, кількість таблиць ...)
  • Визначте, які модулі занадто великі
  • Дублювання.
  • Дотримання стилю коду
• Дефектна ставка
  • за KLOC за модулем або підсистемою (визначте проблемні частини вашої системи)
  • Ви можете порахувати, скільки на кожного члена команди, але я думаю, ви повинні це зберегти для себе
  • вирішено vs знайдено
  • час, необхідний для вирішення помилки (можливо, якщо це має намір зробити графік цього)
  • можливо, зробіть оцінку, скільки часу потрібно, якщо це триватиме за поточною швидкістю
• Планування
  • Екстраполяційний час, який використовується для побудованих функцій. Враховуйте складність функції. Це не повинно бути дуже точним. Те, що ви хочете донести до цього, було б уздовж рядків "Особливості A, B і C мають приблизно однакову складність D, E і F. Якщо функції ABC використовуються 170%, якщо запланований час. Якщо нічого не зміниться, ми очікуємо того ж потрібен час для DEF "або уздовж рядка" Середня функція займає X% час довше, ніж розраховано. У нас немає підстав припускати, що решту функціональних можливостей простіше побудувати, тому ми повинні компенсувати це в майбутньому плануванні Планування плану, якщо воно не є реалістичним, не має сенсу.
  • Спробуйте мати щомісячний або бажано навіть коротший графік випуску. Якби тільки внутрішні. Це може допомогти вам додатково в екстраполяції часу, необхідного для проекту. Це також може врятувати вас від прийняття нереальних зобов’язань (якщо ви не покладете на нову роботу до того, як буде зроблено реліз). Складіть план для кожного циліндра і переконайтеся, що нові функції входять лише в наступний цикл (тобто вони ніколи не можуть бути додані до поточного циклу).
• Тестове покриття: поясніть "нормальні" значення тестового покриття та покажіть, яким є поточне покриття
• Документація: Скільки фактично задокументовано? Як добре?
• Модульність:
  • Клас на основі (з'єднання та згуртованість)
  • На основі пакету
  • На основі підсистеми (скільки шляхів спілкування існує?)

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

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

Крім того, поки графік може сказати, що залишилось 1 1/2 місяця. Це, мабуть, не "краплі мертві" дати. Деякі клієнти можуть взяти те, що ви маєте до цієї дати, навіть якщо це ще не все. Деякі замовники можуть знайти додаткове фінансування, оскільки вони вже вклали багато коштів у проект. Іноді сама компанія може взяти на себе додаткові витрати, щоб забезпечити задоволеного клієнта. Все це поза вашим контролем. Робіть свою роботу якнайкраще. Це дасть варіанти управління для роботи з цим, що може перетворити проект катастрофи у велику історію успіху. Я бачив це багато разів.

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

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

Слідкуйте за технічними аспектами вашого Маршу смерті. Коли ви отримуєте неминуче запитання про інтерв'ю , чи були у вас невдалим проектом; чому це не вдалося і що ви зробили, щоб спробувати запобігти? Управління кістковим головою - це не відповідь, навіть якщо це причина.

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

Те, що ви розглядаєте як повний провал, може не сприйматися таким як таке, залежно від точки зору. В ідеальному світі кожна функція була б завершена, шифрована елегантно та незалежно від інших систем та кожного тестового рядка коду. Я не бачив жодного проекту, який би виглядав таким чином у версії 1. У реальному режимі доставка проекту означає прийняття певних компромісів, можливо, навіть відсутні деякі ключові функції, але продукт може доставляти, і хоча це буде бета-якість у кращому випадку , принаймні ви отримаєте відгук про те, які речі потрібно виправити спочатку. Переваги цього полягають у тому, що він може повідомити керівництву, що програмне забезпечення ніколи не робиться, а замість того, щоб намагатися розробити певний v 1.0 у вакуумі, краще проінтерувати та реагувати на зміни спритно. Нарешті для вас як розробника на цій посаді, Я думаю, що головне - розробити якомога кращий код в цих умовах - документуйте його, пишіть тести самостійно, якщо вам доведеться (особливо для зовнішніх залежностей) і використовуйте свої знання системи, щоб повідомити, які функції є справді важливими і повинні -як і які можуть чекати тиждень чи місяць. Будьте голосовими щодо своїх проблем і виправдайте їх так, як ви це робили з нами. Замість того, щоб підготуватися до плану B, підготуйтеся до того, що ви та інші бідні душі, ймовірно, будете виправляти все те баггі та ще не зроблений код ПІСЛЯ доставки товару - як зазначено вище, це означає писати свій код модульно роз'єднаним способом - якщо ви вважаєте, що код стійкого шару поганий, сподіваємось, ви зможете повністю замінити його в наступній редакції. Нарешті, не впадайте у відчай - вирішення такої ситуації є частиною того, що ви ' вам платять за це, і це процес навчання. Незалежно від результату цього конкретного проекту, це буде вважатися цінним досвідом у майбутньому.