« Думати - важка робота » , або 3 причини невдалих проектів

via Shutterstock .

[ Від редакції : автор , який надіслав дану статтю , побажав залишитися анонімним ]

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

Розглянемо « кейс з життя». Він містить гострі кути , удари про які я спостерігав неодноразово , і ідеально підходить на роль моделі для подальших міркувань .

Кейс

Програмістові Васі приходить в голову геніальна ідея - створити чергову соціальну мережу. Він вміє робити бек- енд , але не вміє фронт -енд. Вася йде до Петі , що знає HTML5 , і до Колі , знайомому з Photoshop. Разом вони на колінах пишуть симпатичне веб -додаток. Зірки і фаза місяця збігаються, і дітище програмістів купує якась американська контора « А».

СТО з А усвідомлює важливість знань , і тому призначає своїх підлеглих Майкла і Стіва перейняти знання у Васі , Петі і Колі . Майкл і Стів поняття не мають , що таке 100 % знань , і вірять українській команді на слово.

Вася , Петя і Коля проводять knowledge transfer за 3 дні, потім підписують всі необхідні папери і зникають в невідомому напрямку з наміром красиво пожити на зароблені гроші.

10 грудня 2999 . СЕО з «А» за всіма правилами SMART ставить перед СТО задачу розгорнути до 1 липня 3000 « куплене скарб» всередині корпорації. Для цього СТО має вкластися в бюджет $ 500 000 і провести інтеграцію з існуючими системами обліку кадрів і робочого часу.

СТО , сидячи ввечері зі склянкою чогось , намічає в голові план дій :

  1. 1 січня - 01 лютий - провести тендер між 5 компаніями- розробниками ( вендорами ) ;
  2. ... зажадати план від вендора ;
  3. 1 липня - накрити урочистий фуршет і чекати нагороду за виконання поставленого завдання.

На наступний ранок СТО приходить з цим планом до СЕО . Цього ранку зірки і фаза місяця виявляються не зовсім підходящими . Тому , незважаючи на всі витрачені на бізнес-навчання годинник , розмова СТО і СЕО зводиться приблизно до наступного :
- Зробиш це до 1 липня ?
- Так, мій повелитель .

На тому й порішили.

На вибори вендора СТО витрачає два місяці , а не один , як предпологал . Нарешті 25 лютого компанія « А» і вендор підписують контракт за моделлю TnM (замовник платить за « час і матеріали »). Проект вирішено вести з Agile у вигляді SCRUM . У договорі прописано , що буде Спринт 0 і « решта спринти , які ми визначимо потім». У ролі продакт овнера виступає Стівен .

Після підписання контракту на стороні замовника :

На стороні вендора :

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

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

Подібні проекти вражають кількістю проблем і ризиків. Сторонні спостерігачі запитують: «Як ви могли зробити таку дурницю ? » Але команда дивиться « зсередини». Менеджер пообіцяв завершити розпочате , і на кону стоїть репутація компанії, бізнес замовника , ссобственное обличчя і «безпека» робочих місць.

3 причини невдачі

Розглянемо 3 основні причини, які з 100% гарантією приведуть вас або до тягнеться нескінченно « мертвому » проектом, або до гучного скандалу і ярлику « не здатний ».

1 ) Непорозуміння

У розглянутому кейсі компанії підписали контракт на Time and Materials , але - поклавши руку на серце - СТО зміг би реалізувати свій план тільки по Fixed Price . Він не хотів особливо морочитися , і збирався «все зажадати від вендора ».

Крім цього , три людини навряд чи впораються з ризиками , притаманними подібного проекту . Менеджери потрапили в распостраненное пастку , підписавши TnM контракт з Fixed Price очікуваннями.

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

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

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

2 ) Припущення

Ось короткий перелік припущень , що ведуть до сумних наслідків :

Замовник :

Програмісти :

ПМ на стороні вендора :

Менеджмент вендора :

Згадуючи Біблію , наведу цитату , актуальну для всіх учасників : « Бо хто з вас , коли башту , не сяде й видатків не вирахує , чи має він , що потрібно для здійснення її , щоб, коли покладе підставу і не зможе вчинити , усі, хто бачити не стали сміятися над ним , говорячи: Чоловік цей почав будувати і не міг закінчити ? »

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

3 ) Неправильне/недостатнє розуміння своєї ролі і обов'язків

На жаль , при розробці ПО « сума частин » не завжди складає « ціле».

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

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

Як уникнути проблем

Як висновки я пропоную 5 рекоммендаций , які допоможуть не допустити описаних конфліктів .

1 . Завжди враховуйте , що навколишній світ динамічний. Те , що не мало значення вчора , може стати на чолі кута завтра .

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

3 . На кожне зроблене припущення опрацьовуйте сценарій на випадок його помилковості . Користь :

4 . Пам'ятайте про принцип Win- win і напомайте про це керівництву. «Гра в одні ворота» хороша до пори до часу.

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

5 . Ставайте професіоналом, а не просто програмістом , тестувальником або ПМом .

Розберіться , чим займаються люди , які стоять поруч з вами в ланцюжку виконання загальної задачі . Тоді ви будете розуміти , де саме тестувальник « недотестіровал » , програміст « ??недопрограмміровал » , ПМ недодумав , не до кінця зрозумів або не все врахував.

Це потрібно для того , щоб найбільш ефективно розпоряджатися своїми ресурсами . Безглуздо витрачати на завдання в 3 рази більше часу тільки через те , що ви « не побачили » даний стан справ.

« Думати - найважча робота . Ось , ймовірно , чому цим займаються настільки небагато ». Генрі Форд


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

Можлива тематика циклу статей:
- Життєвий цикл проекту « з висоти пташиного польоту »
- Ролі в проекті і їх взаємодію
- Типи замовників і методи роботи з ними
- Це страшне слово « Enterprise »

Опубліковано: 13/03/14 @ 11:09
Розділ Різне

Рекомендуємо:

Java дайджест # 1 . тестування
Як перенести e - mail передплатників з Feedburner на Smartresponder
21 березня, Одеса - Конференція Малої Академії комп'ютерних Наук в Одесі
New It in New Ukraine
Дайджест цікавих вакансій № 127