Впровадження CRM без ТЗ: дорога в нікуди

Доробка типового програмного забезпечення під вимоги замовника — це буденна справа, якщо воно правильно організовано. Проте часто можна зустріти приклади, коли розробники беруться виконати роботи без ТЗ (технічного завдання) на вимогу замовника. Що відбувається в результаті? Обидві сторони заганяють себе в яму, яку викопали самі. Розробник не підозрює, що він буде змушений виконати обсяг робіт у багато разів більше передбачуваного, і рано чи пізно зупинить ці роботи, наковтавшись роздулися апетитів замовника, які будуть зростати в геометричній прогресії, не маючи формальних обмежень. У такій ситуації розробник ризикує ніколи не завершити роботу, а замовник — ніколи не отримати потрібного результату. На ранніх етапах розвитку компанії ми в цій ямі побували неодноразово, тому пропонуємо другу частину наших історій про ТЗ — коли його немає.



Перша частина про те, як складати технічне завдання посилання.

Ми — розробники CRM. Наша RegionSoft CRM — досить потужне професійне рішення для бізнесу. Десктопна Система і нам дуже часто дістаються клієнти, яким потрібен повноцінний проект впровадження із заточуванням під індивідуальні особливості клієнтів. У когось це особливий цикл продажів, комусь потрібно відстежувати транспорт, третім необхідні особливі звіти, налаштування системи KPI або бізнес-процесів. Плюс, ще зустрічаються особливості впровадження, наприклад, розподілені офіси, філії, налаштування телефонії, торгового обладнання і т. д.

Зокрема CRM, а в цілому для будь-якого корпоративного програмного забезпечення підходить схема: ліцензії + доопрацювання + впровадження. Клієнт може придбати ліцензії, встановити, самостійно взяти документацію, розібратися і почати працювати. Може купити ліцензії, замовити доопрацювання, а решту зробить сисадмін. А може купити ліцензії та замовити впровадження. Ну і зв'язка з усіх трьох елементів також можлива. Так от, етапи доопрацювання та впровадження завжди вимагають складання технічного завдання, в якому будуть поетапно вказані всі роботи, строки, ціни та інші умови.

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

  • І так все зрозуміло — навіщо витрачати час?
  • Тут все просто! Та я на пальцях поясню.
  • Я не вмію його складати.
  • Чому я повинен платити за те, що увійде в наступний реліз?
  • Ви складаєте ТЗ за гроші?!
Давайте розглянемо ці питання в деталях, тому що одним абзацом списку явно не обійтися.

ТОП-6 фраз клієнтів — вірний спосіб розсердити розробника
І так все зрозуміло — навіщо витрачати час?
Коментар розробника: Щоб визначити чіткі завдання та цілі, формалізований їх на папері. Адже те, що обговорюється усно, не можна використовувати в якості прямої вказівки до дії. Також, усні домовленості згодом легко трактувати кому як зручно. А якщо ТЗ об'ємне і вимагає тривалого терміну реалізації, хто потім буде згадувати про те, які саме формулювання використовували сторони, коли обговорювали вимоги до доопрацювання?
У нас є базове рішення — CRM, до неї є вимоги щодо доопрацювання. Буває, ми беремося за розробку цілих модулів або додаткового до CRM програмного рішення (як у нас вийшло, наприклад, GeoMonitor і RegionSoft Retail). У клієнта є бізнес, який він хоче автоматизувати. У нього є набір проблем, які ця автоматизація повинна вирішити: підвищити продажі, впорядкувати процеси, скоротити час на рутину, зробити прозорими угоди та склад і т. д. Нам зрозуміло, як працює наш софт, клієнту — як функціонує бізнес. І коли ми зустрічаємося, то повинні зрозуміти один одного.

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

Як зрозуміти один одного, працюючи над ТЗ?

  • Говорити на общепонятном русском (іншою) мовою. Навряд чи кожен клієнт зрозуміє фрази «бэкапить базу на резервний сервер» або «накатим апдейт на продакшені». Потрібно вислухати обидві сторони: розповідь вендора про можливості софта, розповідь клієнта про потреби бізнесу, задати питання і приступити до складання ТЗ саме за тим фічами, які реально потребують доопрацювання.

  • Робити технічне завдання поетапним: розділити майбутні роботи на блоки із зазначенням суми і термінів по кожній з груп робіт.

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

Тут все просто! Та я на пальцях поясню
Коментар розробника: Буває так, що невелика зміна в одному механізмі каскадом тягне цілий набір пов'язаних змін в інших місцях, що необхідно проаналізувати і врахувати при підготовці до робіт. Буває і так, що для реалізації начебто простої задачі потрібно внести суттєві зміни в движок механізму, змінивши його архітектуру. Складання ТЗ допомагає продумати ці моменти і виробити правильні рішення, в результаті чого робота буде виконана якісніше, з меншою кількістю помилок і налагодження, а в процесі розробки буде менше підводних каменів і «сюрпризів».
Замовнику здається, що змінити цикл продажів, створити один звіт або прикрутити діаграму Ганта — просто. Більш того, напевно він погуглив або йому розповіли, що це робиться в кілька десятків рядків коду. Так, сам код перерахованих сутностей досвідченим програмістам по плечу, але замовник не здогадується про те, що все це потрібно вмонтувати в архітектуру основної програми і заради «ну там невеликий доработочки» доведеться грунтовно змінювати логіку якого-небудь модуля або системи.

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

Я не вмію його складати
Коментар розробника: Але Ви ж можете простою мовою озвучити вимоги до функціоналу, які повинні бути створені. Це можна зробити в тезисном вигляді, а деталі обумовити усно. Але в підсумку, ТЗ становить розробник на основі Ваших вимог і з урахуванням всіх деталей. Адже Ви не вправі розраховувати на те, що Вам будуть зроблені роботи, не обумовлені в ТЗ! Ви за них навіть не платили… Вірно?
Виходить, головне — донести вимоги. ТЗ — це робочий документ для того, щоб зрозуміти призначення, цілі і бачення продукту. По ньому буде підписувати акт, по ньому ж будуть вести розробку програмісти з команди вендора. Для них це — інструкція, згідно якої вони просуваються в розробці. ТЗ — зовсім не обов'язково 100 сторінок (хоча буває і 400, ну це у великих інтеграційних проектах), це може бути і пара пунктів, але вони обов'язково мають бути. Клієнт, у свою чергу, зможе прийняти роботи, звіряючись з технічним завданням — і у випадку колізій показати розробнику на те, що зроблено не так. Ну або навпаки.

Чому я повинен платити за те, що увійде в наступний реліз?
Коментар розробника: Ніхто заздалегідь не знає, чи увійде доопрацювання, замовлена Вами, типове рішення в майбутніх релізах. Це визначається набагато пізніше на раді розробників при підготовці глобальних оновлень. Проте дійсно, будь-яка доопрацювання при її корисності для широкого кола споживачів, може бути включена до типове рішення. Це право розробника і воно не обговорюється.
У нас є така практика — кращі рішення і доопрацювання ми вводимо в реліз. Хто бачив RegionSoft CRM ближче, могли помітити, наскільки вона функціональна і глибока за набором можливостей. Це досягається саме за рахунок безперервного впровадження нових функцій, в тому числі з клієнтських запитів.

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

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

  • Замовник сам — консультант вендора, і коли він розуміє, що хоче, розробнику набагато легше.

  • Вендор розбирається в бізнесі хоча б в силу того, що він сам по собі бізнес і працює зі своїми продуктами як клієнт. Наприклад, у нас в Регионсофт у всіх співробітників варто RegionSoft CRM — ми її використовуємо за всіма сценаріями: як інструмент продажів, викликів, розсилок, багтрекер, журнал кореспонденції, інтегруємо з 1С, ставимо завдання, плануємо, оцінюємо KPI та ін. Відповідно, є чітке уявлення про те, як працює середній клієнт. До речі, відмінний спосіб тестування програми.
Як правило, компанія-розробник завжди експерт в тій галузі, для якої вона розробляє. Без цього можна писати окремі скрипти і модулі, але ні в якому разі не комплексні системи.

Ви складаєте ТЗ за гроші?!
Коментар розробника: Для того, щоб скласти ТЗ, необхідно виконати певний обсяг робіт. Це можуть зробити тільки фахівці з досить великою кваліфікацією, які знають систему зсередини і розуміють бажання замовника. Це непроста робота. Часом від продуманого і якісно складеного ТЗ залежить весь успіх реалізації проекту.
Звичайно, за простеньке ТЗ з двох-трьох пунктів гроші не беруться. А от за решту потрібно платити як за частину проекту. І тут є ряд економічних, функціональних і навіть психологічних причин, про які варто розповісти докладніше.

  • Співробітники, які складають ТЗ на стороні розробника (як правило, це 2 особи і більше), витрачають на нього свій робочий час, зрушуючи інші завдання. Відповідно — це робота.

  • Після складання ТЗ клієнт може піти до конкурента з готовим «подарунком» — чому ми повинні їм оплачувати цей етап роботи?

  • ТЗ — це частина інтеграційного проекту, і певні функціональні роботи проводяться ще на етапі його складання.

  • Те, що дано безкоштовно, не цінується — клієнт відноситься до документа як до необов'язковою бюрократичної формальності. В той час, як це має бути основний робочий документ.
До речі, «інвестування» в ТЗ найчастіше призводить до набагато більшої, ніж його вартість, економії: ви платите тільки за точні, обґрунтовані доопрацювання. Але це не означає, що склавши ТЗ, не можна більше внести жодного зауваження. Можна. Попередньо внісши додаткові роботи існуюче технічне завдання.

Я мав на увазі інше!
Коментар розробника: Думки людини несповідимі. Сьогодні я хочу зелений чай, а завтра мене потягне на каву. Якщо немає ТЗ, то неможливо спрогнозувати, що замовник мав на увазі, коли говорив, наприклад, що «по натисненню на зелененьку кнопочку повинна відбуватися інтеграція з 1С». Що це означає? Трактувань може бути маса. Може потрібно завантажити оплати з 1С в CRM? А може вивантажити рахунки? Чи потрібно вивести звіт про складські залишки? У ТЗ повинна бути однозначність.
Якщо вендор йде на поступки і погоджується працювати без технічного завдання, то він, швидше за все, почує саме це заперечення, коли настане момент підписувати акт виконаних робіт. І заперечити, вибачте за тавтологію, йому буде нічого. Так само як і довести, що клієнт повинен платити за перероблення всього, що йому надано. Але відсутність ТЗ робить беззахисним не тільки розробника, але й самого клієнта.

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

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

Бізнес-аналітики та ТЗ
Це настільки хрестоматійна і нестерпно жахлива історія, що їй обов'язково варто присвятити окремий блок посту. Моду на бізнес-аналітиків ввів SAP. І вони у SAP по всьому світу дуже потужні хлопці з сильним технічним, фінансовим та менеджерським бекграундом. Саповцы, особливо за кордоном, відмінно знають ціну часу, термінами, ТЗ. В Росії, мені іноді здається, вони перейняли тільки напір у спілкуванні, випрасувані костюми і слова типу митап, кол, фідбек, фоллоу-ап (поспілкуйтеся при випадку — бізнес-аналітики прикольні хлопці!). У нас я зустрічав бізнес-аналітиків з гуманітарною освітою, з незакінченою вищою і навіть без знання основ роботи з ПК. Це такі продажники на стероїдах. І ось вони виступають адвокатами угоди і беруться складати ТЗ. Тут можливі варіанти.

Все ж готове — беріть і робіть! На моїй практиці є кілька десятків випадків, коли люди приходили з готовими великими ТЗ, підготовленими сторонніми консалтерами. Однак жодна з них так і не дійшла до реалізації. Всі грязло в обговоренні цього великого ТЗ. На цьому й закінчувалася. В даному випадку ТЗ вам пише зовсім стороння людина, який знає, як веде себе CRM в бізнесі в загальному випадку (фактично стерильні лабораторні умови), але зовсім не знає, як поведе себе обрана вами програма у вашому власному бізнесі. Або ж він складе вам ТЗ таким чином, щоб під нього підійшла не та програма, яка вам потрібна, а одна з тих, яку йому потрібно продати за відсоток від угоди.

Ось тут же все про CRM! Люди приходять знову ж від бізнес-аналітиків з готовим ТЗ, яке абсолютно не погоджено з нашим і для його реалізації потрібні величезні гроші, оскільки потрібно перепиливать складні механізми системи, замість того, щоб адаптуватися до системи і доповнити її відсутніми можливостями.

Тут у нас в 2010 році CRM купувати хотіли, ТЗ завалялося. Старе технічне завдання — це мертве технічне завдання. Бізнес-процеси змінилися, куратори проекту вже інші, модернізувалася ІТ-інфраструктура, зріс рівень CRM-систем. 7 років для бізнесу та ІТ-сфери — це значний час, як рік чи два, тому старе ТЗ просто не актуально.

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

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

Отже, підіб'ємо підсумок міркуванням.

  • Технічне завдання повинно складатися на будь-яку доопрацювання і будь-яке впровадження.
  • Над технічним завданням завжди працюють дві сторони.
  • Складати ТЗ вигідно і замовника, і підрядника.
  • Технічне завдання не повинно бути формальністю або елементом бюрократії.
  • ТЗ — основний інструмент команди програмістів.
  • Старі, шаблонні, чужі ТЗ нічим не допоможуть вашому проекту.
  • Складання ТЗ значно прискорює терміни здачі проекту.
Технічне завдання — перша і важлива частина інтеграційного або впроваджувального проекту. Саме від нього залежить, наскільки швидко і якісно команда впорається з роботою, а замовник отримає бажане, працює, як годинник. За кордоном з'явилося багато адептів роботи без ТЗ, вони ратують за свободу творчості і довірчі відносини, війни розгортаються навколо слова «вимоги» (Product Вимога Document). Насправді, це холівар заради холивара — працювати без технічного завдання в корпоративній сфері як замовнику, так і вендору неможливо. Треба вміти домовлятися. І поля ТЗ — найкраще місце для цього.



А ми просимо тих, хто не пройшов, пройти опитування про CRM, про результати якого обов'язково розповімо перед самим Новим роком — в тому числі про механіку опитування і своїх одвірках. Просимо вас відповісти на питання в простенькій формі — їх всього 10 плюс 3 для тих, кому цікаво дізнатися про нас більше. Прохання дійти опитування до кінця, непотрібні вам пункти просто пропустити.

Пройти опитування тут
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.