У нас на паркані папері написано дуже багато букавок про те, як керувати проектами. Стільки ж, якщо не більше закорючок присвячено тому, які історії успіху з цього виходили. Нудотно, нецікаво, задовбало. Розглянемо історію одного провалу, адже це завжди цікавіше і привабливіше (мабуть, в силу натури людяної більше зловтішатися, ніж радіти). Приступимо.
На початку було бажання
Рядовий проект. Не простий, але й не особливо складний. Щоб не йти в дебрі пальцетикання, назвемо його проект 1. З компанією А. Яка є виконавцем одного важливого завдання компанії Б. Дуже великої, та ще й специфічної у своїй продукції, а як наслідок, дуже люблячої за свої великі гроші приносити великий мішок радості у вигляді доопрацювань і погоджень на голову тих, хто працював з нею. І є представник компанії А на ім'я В, і є його начальник Г. Туману напустили, смуток в голови читача вселили, можна рухатися далі.
Етап 1
Ну що сказати. Досить цікавий етап, цікавий тим, що на просторах аутсорса є пересічним у класичному розумінні. ТЗ представляє собою якусь мішанину з букавок на якомусь сторонньому ресурсі, що надає щось в роді фліп чату галактичних масштабів, який можна скролити до нескінченності, бродячи по хитросплетінням стрілочок, залежностей і підписів. Ворох документів, оформлених чому то у вигляді презентацій і файлів екселя, ну та годі, нам не звикати.
Побіжно ознайомившись з цим звіринцем, я вирушаю в офіс компанії А, щоб поговорити з В про те, чого ж вони насправді хочуть. Години за 4 формується набір начерків інтерфейсу, логіки роботи програми, з'являється розуміння того, що мішанина множень, віднімань, поділів та інших дужок в екселі претендує на роль розрахунку бізнес-процесу. І навіть з'являється розуміння того, як це робити. Досягаються домовленості щодо реалізації, термінів, оплати - в бій. Через деякий час з'являється програма.
Міжсезоння
Простий проект поступово починає доповнюватися осенізмами. Осенізм - це вимога, яка з'являється у замовника в процесі роботи над програмою. Як правило, це даність. Я ще не зустрічав жодного проекту з понад 120 проектів з розробки веб, десктоп, вбудовуваних систем і коду для мікроконтролерів, в якому б він чітко відповідав початковому ТЗ. Якщо ви вірите в перебіг марсіан і в трьох слонів на трьох китах - то будь ласка, можна так само сліпо вірити у фіксоване ТЗ. Але, як правило, під час роботи спливають нюанси, ідеї, та й просто «тидищ забув» - я, принаймні, звик. Але на якомусь з етапів ієтрацій доробок я почав розуміти, що вони все більше і більше зачіпають бізнес-логіку, і почав активно цей процес згортати. Бізнес логіка - наріжний камінь ПЗ, і якщо її немає, то це проблема схоже на падіння метеорита порівняно з розлитим кефіром, яким є «ой тут кнопочку». Ми домовляємося про другий етап.
Етап 2. Шлях до краху
На цьому етапі В пропонує, а я погоджуюся на те, що В, будучи програмістом, який писав для компанії А ПО, а потім перейшов в штат, напише нову бізнес логіку мовою програмування. На якому - не важливо, важливо - відмінному від мого. Та й це, власне, не важливо, якщо це тільки не брейнфак - мови приблизно однакові, і при наявності документованого коду розібратися з тим, що робить програма, суть якої - обрахувати дії користувача, досить просто. Як виявилося, це мені так здавалося, вже вибачте за каламбур. Не буду засуджувати манеру розробки ПЗ. Буває всяке, бачив різне. Самолічно читав при реверс інжинірингу прошивки блоку управління одного дуже великого автовиробника коменти, які змушували ржати в голос, а деякі рішення, застосовані в цьому ПЗ, приводили в жах. І нічого - мабуть, у продакшні (раз я це читав), і їздить у мільйонах проданих авто. Важливо інше. Дебаг коду, переписаного за правилами, зайняв в 4 рази більше часу, ніж планувалося. Була навіть крамольна думка скопіпастити код і зробити конвертор зі структури даних в той набір змінних, а за підсумками відпрацювання коду - конвертувати назад.
Трошки дозволю повернутися до початку. Компанія А робить продукт для Б. Дуже великої Б. До якої ходять періодично показувати проміжний результат. Навіщо - не зрозуміло. Бо після кожної зустрічі я отримую ще купу вимог до візуального оформлення і логіки взаємодії з користувачем. З внесенням нової логіки до ще не відпрацьованого коду. З ще більш урізаними термінами після кожної зустрічі. Потік детерменованого хаосу наростає.
Як підсумок - співробітник В відсторонюється керівником Г від робіт, і Г бере справу в свої руки. Теж спірний момент. Бізнес-логіку я отримав у вигляді коду as is. На звірці при передачі було дуже багато круглих очей - у мене від того, що я дізнавався, що мені не дали банальні вимоги до софту, які були і, що найголовніше, не були «супер _ топ _ секрет». У Г - коли він вникав у сенс логіки, що коїться в бізнес, яка була ускладнена на кілька порядків від необхідного.
Біда, туга і засмучення.
Підсумок?
Я чудовий програміст. Я все здаю вчасно. Завжди. Я не роблю помилок. Я пишу ідеальний код. Всі замовники - скоти і олігофрени, не розуміюче, як їм пощастило.
Начебто нічого не забув. Так треба було б закінчити цю історію. Якби я хотів поплакатися в жилетку. Але пам "ятайте початок статті? Давайте на прикладі факапа, а не історії успіху розберемо те, що треба було робити. Всі ми сильні заднім розумом, тому банального «треба було записати всі вимоги в ТЗ, підписати договір і сидіти на жопі рівно після виконання ТЗ» я писати не буду. Ця помилка очевидна як божий день, та й помилкою її назвати складно - пам'ятаємо про марсіани і слони.
Помилки
Відсутність приїзду перед початком другого етапу. Пам'ятайте - на першому я приїхав і ми проговорили роботу. На другому я цього не зробив, будучи впевненим в тому, що це те ж саме, тільки в профіль. Як підсумок - я отримав чимало доробок «ось це пересунути, а тут додати».
Згода на код замість текстового завдання. Одна з ключових помилок, навіть страшніша за першу. Про це славне «я коли те»..... У кожного є це «колись». Я теж коли то ремонтував автомобілі. Навіть був власний сервіс. І це не слабо допомагає мені, коли на СТО мені починають нести відверту нісенітницю. Але властивість нашої пам'яті така, що ми пам'ятаємо гарне, а погане стирається. Так, я кинув автомобілі тому, що віддавав весь час роботі, і просто згорів. Нудити стало. Але чи пам'ятаю я те відчуття, коли нудило? Ніа. Це просто набір букав. Факт. Голий. І все. А ось бухалово вечорами в компанії хлопців, покатушки, цікаві проекти з тюнінгу, кумедні випадки - пишу і на обличчі посмішка, їй богу. Мине ще п'яток років, і може я знову вплутаюся в автомобілі. Як знати?
«Коли те» дуже тісно пов'язане з приємними спогадами. І тому - здається простим, кумедним, цікавим. І коли модель, яку обіцяв передати в роботу, раптом не працює, коли реальність тикає тебе носом в те, що код треба дебажити (який, до речі, виявив вже після вразливості за граничними умовами) - тоді так, як то на роботу таку вже й не стоїть пріоритет. І радості немає. Ніякої. Тому і логіка мені була надіслана із запізненням в 6 разів від заявленого.
А я - вислоухий дурень. Прекрасно обізнаний про те, що таке «я колись кодив». Прекрасно знає, що це найжахливіший замовник. Але, тим не менш, поведеться в черговий раз.
Згода на доопрацювання. А точніше - відсутність їх контролю. При роботі я намагаюся виконувати не більше 10% переробок від вихідного завдання перед проміжною або фінальною здачею. Тут рахунок був втрачений, мною ж.
Згода на урізання термінів. «планування-проектування-написання-тестування». Чудес не буває. Якщо терміни від заявлених урізаються в 2 рази, то це призводить до їх збільшення в 2 рази. Так як щось в будь-якому випадку буде опущено, і призведе тільки до збільшення результуючого терміну (а не терміну, коли рапортується про «готовність»).
Ось і все на сьогодні. Сподіваюся, досвід буде корисний камрадам. Доброї ночі.