На які попереджувальні ознаки насувається приреченість, на яку слід стежити за проектом? [зачинено]

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

Ці проекти можуть бути чудовим досвідом, руйнуванням душі (або обома!), І можуть траплятися з безлічі причин:

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

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

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

На які попереджувальні знаки ви звертаєте увагу, щоб увімкнути звуки тривоги, що насувається в голові?

Героїчне кодування

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

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

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

Крім того, одного разу вам доведеться пояснити керівнику проекту, чому після 6 місяців роботи ви майже до 85% можливостей і 150% помилок, які мали додатки, коли ви починали роботу.

Новий інструмент як вирішення проблем.

Коли люди починають планувати користуватися незнайомими інструментами, я не проти, але я стежу за цим. Коли вони починають планувати всі рекламні переваги цих інструментів у графіку, я хвилююся. Веселі приклади:

• Ми можемо поголити місяць від розкладу, тому що ми будемо намагатися використовувати об'єктно-орієнтовану мову (хоча все, що ми маємо, - це розробники).
• Ми спробуємо цю нову проблему, яка вирішить усі наші проблеми з процесом!
• Я знаю, що це вже на півдорозі проекту, але що робити, якщо ми змінили ORM на щось нове?

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

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

Так в основному; Ніяких письмових вимог

Це поцілунок смерті.

Відключення управління

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

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

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

1. Коли ключові розробники відходять, а управління не хвилює

2. Коли ключові розробники відходять, і ніхто з інших розробників не піклується

Як правило, номер один вказує на менеджерів, які сильно не вписуються в динаміку команди (хто «10-красна суперзірка», хто гідні програмісти і як вони взаємодіють між собою тощо).

Номер два зазвичай вказує на сильну відсутність інтересу з боку інших розробників.

Перший раз, коли хтось, як правило, керівництво каже: "у нас немає часу на .."

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

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

Коли управління занадто слабке, щоб сказати "Ні" бізнесу.

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

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

Ще одна вірна ознака того, що виникає невдача - це присвоєння нових розробників найважчій і найскладнішій, найважливішій частині процесу, а не людям, які вже розуміють поточну систему. Тоді не слідкуйте за ними уважно, щоб побачити, чи справді вони завершують роботу належним чином чи у вас є запитання (ВЕЛИКИЙ ВЕЛИКИЙ КРАСНИЙ ФЛАГ, якщо немає питань). Необхідно стежити за новими працівниками до тих пір, поки ви не дізнаєтесь, що вони справді мають навички, на які вони заявляли. Я все ще пам'ятаю, як провів одне болісне літо, переробляючи роботу (вже минулий термін, коли я її отримав) нового працівника, який отримав критичну частину проекту і сказав усім, що все було нормально місяцями, а потім пішов без повідомлення через тиждень від граничного терміну і нічого, що він робив, було корисно.

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

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

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

Коли нетехнічні менеджери починають наполягати на прийнятті технічних рішень, які вони ні в якому разі не можуть приймати. Великий, великий червоний прапор!

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

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

Нудно члени команди.

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

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

(Cribbed з динаміки розвитку програмного забезпечення Джима Маккарті ).

Ковбойські кодери, великі егої та прийняття їх керівництвом

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

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

Розробники Running Wild на дальності

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

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

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

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

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

Прем'єр-міністру навіть не вистачало духу полетіти на CDR (Critical Design Review), щоб лише зірвати зустріч із клієнтом і кинути приступ. Коли він вимагав сплатити його витрати на проїзд у рамках проекту, йому було ввічливо сказати піти з собою.

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

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

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

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

Коли менеджери здійснюють код на День подяки.

Коли ви почнете отримувати електронні листи, що мають печатку про дату пізніше 11 вечора та раніше ніж 6 ранку.

Коли на кожне запитання про те, як впоратися з деякими труднощами, зустрічається однакова відповідь: "Не хвилюйтесь про це ще".

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

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

Коли команда бази даних та команда із заяв не розмовляють між собою.

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

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

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

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

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

• Компанія вирішує мати молодших розробників, які розробляють та розробляють нові функції, та призначає більш дорогі старші розробники для виправлення своїх помилок.
• Компанія передає найважливіші компоненти програмного забезпечення компаніям третього світу, які не мають необхідного досвіду в галузі.
• Цикли хрускоту час наближаються до того, що здоров'я людей руйнується.
• Таблетки, які веде ваша команда, приймають наркотики, щоб спати щовечора, перестаючи працювати.
• Клієнт надсилає замовлення на зміну швидше, ніж ви можете їх аналізувати.
• Ви повинні доставити кілька років роботи протягом кількох тижнів, але керівництво відмовляється робити функцію заморожування.
• У ваших постачальників обладнання очевидно виникають проблеми з доставкою працездатного продукту за графіком, і ті, хто приймає рішення у вашій компанії, не розглядають жодних альтернатив.
• Розробникам прототипів потрібні розробники пристроїв, щоб вони мали шанс зустрітися з ймовірно нереальним графіком, і його відбирають та надають топ-виконавцям, щоб вони почували себе добре.
• Перший тиждень: "О, лайно, код баггі. Усі кинули робити нові функції та виправляти помилки." Другий тиждень: "О, дерьмо, ми не збираємось дотримуватися розкладу функцій. Усі кидають виправляти помилки та писати нові функції". Повторіть нескінченно.
• Розробка робиться в одній країні, а контроль якості виконується в іншій країні на півдорозі, тому для зворотного зв'язку про помилку завжди потрібно 24 години, і принаймні один із залучених людей обговорює складні технічні проблеми мовою, якою вони не володіють.

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

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

Через деякий час проект було скасовано, і весь прекрасний код, який я написав, був знятий.

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

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

Я подумки перекладаю "Все добре. Нам нема про що турбуватися". до "Ми всі накручені" щоразу, коли я чую, як менеджмент це говорить. Зазвичай ви чуєте, як керівники випадково кидають це на непов'язані зустрічі ("О, і, до речі, все йде нормально. Немає причин для занепокоєння!"), Але ще більший червоний прапор має зустріч, спеціально покликана сказати це.

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

пару пунктів із мертвого проекту, який я був частиною:

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

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

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

Дивіться цю стисну статтю: Коли ІТ-проекти йдуть правильно .

Відсутність будь-якого з елементів, зазначених у статті, повинна встановлювати дзвінки сигналізації:

Тож переконайтеся, що у вашому проекті є все наступне, якщо ні, то ви повинні бути стурбовані:

(цитую вищезгадану статтю :)

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

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

3. "Третє - розуміння проблем, які потрібно вирішити".

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

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