Як грамотно підійти до складання технічного завдання перед запуском IT-проекту? Що треба врахувати до переказу авансу? Павло Радченко пояснює, як діяти замовнику, щоб досягти взаєморозуміння з виконавцем і потрібних результатів.Всі ми люди, і нам властиво помилятися. Найчастіше наші улюблені самостійно набиті шишки приводять нас до успіху. Але щоб менше набивати гулі, доведеться розвіяти кілька міфів.1) До нашого превеликий жаль, в IT-галузі немає кнопки «зробити все», а якщо вона і є, то вже точно вона не працює як треба, або тільки по осредненному алгоритмом.

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

Все доводиться робити самим, а всі інформаційне (CRM, ERP...) нам в цьому допомагає.
Пара типових бесід

Однією з особливостей вітчизняної IT-індустрії, як і раніше є недбале ставлення до проявів «бюрократії» зразок технічного завдання, пояснювальних записок, документації, докладних актів здачі-приймання та іншим нудним папірців. Логічний наслідок - розмови такого плану:

Замовник: Зробіть нам що-небудь для покращення бізнесу.

Виконавець: Взагалі без проблем, це наше покликання.

Замовник: Відмінно! Стривайте... Ей, а що це ви нам зробили?!

Виконавець: Як і просили, «що-небудь».

Замовник: Нам це не підходить. Переробіть.

Виконавець: Гм. Ну, тоді давайте ще грошей.

Замовник: Що значить ще? Ми незадоволені, переробляйте!

Виконавець: замовлення, він оплачений і виконаний. До побачення.

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

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

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

Замовник: Нам потрібно зробити ось це.

Виконавець: Ок. Ще додамо друк безпосередньо, для зручності.

Замовник: Чудово. Те, що потрібно!

Виконавець: Готове. Друк безпосередньо на Ctrl+Alt+P.

Замовник: Про друк зрозуміло, а як нам...

Виконавець: Не, по бізнес-процесам нічого не знаємо.

Замовник: Що ж нам робити?

Виконавець: Почитайте документацію, може, там є.

Замовник: Ви що, навіть не прочитали документацію до продукту?!

Виконавець: У нас вузька спеціалізація і мало часу. Допобачення!
 
Зрозуміло, що через деякий час такий виконавець подучит матчастину, навчиться нормально спілкуватися з клієнтами і звертати увагу на їх побажання та прохання. Або вилетить з ринку. Але поки це станеться, кілька жертв залишаться один на один з незрозумілими папірцями, - у яких, до речі, може і не виявитися потрібних відповідей. Найприкріше, що в Росії збільшення витрат на проект не означає поліпшення якості. Розмір IT-компанії - теж не завжди гарантія високої якості. Буквально - як пощастить.

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

Перш за все, щоб не стати учасником бесід, схожих на недобрі анекдоти, замовник повинен підготуватися:

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

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

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

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

На верхньому рівні деталізації завдання повинна бути пов'язана з бізнес-інтересами компанії замовника. Наприклад:

Утримати існуючих клієнтів;
Контролювати виробництво;
Підвищувати ефективність;
Прояснити собівартість;
Збільшити прозорість таких бізнес-процесів.

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

Створити систему лояльності;
Автоматизувати контроль якості продукції;
Впровадити систему ключових показників;
Деталізувати фінансову звітність;
Розвинути документообіг з певними выгрузками.

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

До речі, якісна розробка ТЗ становить відчутну частину цієї вартості. В залежності від складності, технічне завдання «важить» від 10 до 40% бюджету проекту! Багато управлінців в Росії вперто відмовляються розуміти цей факт. Точніше, не виходить донести його до замовників досить твердо, щоб перейти від сумних зітхань крадькома до нормальної, загальносвітовій практиці - і рентабельності, відповідно, а також ризик-менеджменту.

Ще один важливий момент: не можна доручати IT-фахівцям розробку ТЗ «цілком». Інакше система наповниться безліччю функцій, які здаються програмістам просто необхідними, але кінцевими користувачами використовуватися не будуть. IT-фахівці - власні і запрошені з боку постачальника IT-рішення - обов'язково повинні брати участь у розробці ТЗ. Вони повинні відстежити і попередити проблеми сумісності, граничних навантажень, кількості користувачів та інших обмежень, нарешті, допомогти записати в термінах, однозначно зрозумілі фахівцям, які будуть розробляти і впроваджувати. На перший погляд здається, що функціональний склад рішення - теж територія компетенції розробників. Але насправді це не зовсім так. Тут повинні попрацювати й «айтішники», і менеджери замовника - щоб домовитися про конкретику, реалізованості, корисності і витрат.

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

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

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

2) Підрядник повинен володіти практичним досвідом - успішним, зрозуміло, та строго по даній ніші. Наприклад, компанія «1С:Франчайзі» за багаторічний досвід впроваджень і підтримки різних продуктів може жодного разу не зіткнутися з 1С:CRM. При зверненні клієнт з великою ймовірністю отримає запевнення в тому, що все буде чудово - але шанси на успіх в реальності досить низькі. Можливо, в штаті підрядника взагалі не виявиться фахівців з потрібними знаннями. Проект, звичайно, завершать. З якою якістю - питання. Проблеми будуть, не сумнівайтеся. Всього наперед не прорахувати, та це і не потрібно. Головне, адекватно оцінити бюджет і терміни, взяти хороший запас і передати оперативне управління фахівцям.

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

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

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

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

Велика частина IT-інструментів - західні технології. Багато «кращі практики», які містять ці рішення також західні, і на вітчизняний бізнес-ландшафт лягають не дуже гладко. Тому їх краще не сліпо копіювати, а використовувати в якості основи, адаптуючи під місцеві особливості і завдання. Тоді російська «неохота», в якій часто грузнуть чужоземні інформаційні комбайни, з фактора ризику перейде в категорію корисного скептичного ставлення до новинок. Використовуйте її на повну котушку при постановці завдання та виборі рішень. А потім наполегливо досягайте результатів - і вони обов'язково будуть.

Наші проекти | Софт | Послуги | Програмування | Оренда сервера | FAQ

Супровід, доопрацювання, консультація, навчання, по програмі 1С. Інформаційно-технічний консалтинг, погодинна і відрядна оплата. Запуск нових проектів, реалізація рішень під ключ.

© 2024 ЕРП ПРОЕКТ