Чому згасає віра у розподілену розробку

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

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

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

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

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

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

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

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

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

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

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

А причина загалом досить проста:

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

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