Не наступайте на наші граблі з ТЗ: епічний досвід конкурсів і пара байок


Широко відомий приклад неточно поставленого ТЗ

Одного разу мені дістався проект, розрахований на півтора року з дуууже важким замовником. Статус: минуло півроку, але все ще йдуть узгодження технічного завдання. Підписалися на одне, але замовник наполегливо продовжував висувати нові вимоги. Завдання ставилося навіть не закінчити вчасно або заробити, а вийти гідно, з мінімальними для всіх втратами.

Було складно — не те слово. У довгому перельоті я читав ТЗ на 20 сторінок. В ньому була така особливість: якщо читати швидко, то може здатися, що воно написано правильно і точно. Але якщо почати копати в деталі інженерної реалізації, то виринало відразу багато нежданчиков. Деякі вимоги підпунктів, начебто 3.2.5 і 4.8.2.9, могли суперечити один одному або бути просто взаємно нездійсненними в реальному світі.

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

Чому не можна узгодити ТЗ відразу?

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


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

Екологічну рівновагу

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

Що ж відбувається далі? Далі настає цікаве екологічну рівновагу.

В поганому випадку:
  • Якщо, побачивши величезну раптово з'явилося ТЗ, виконавець відмовиться від контракту держзамовника за своєю ініціативою, він може бути доданий в «чорний список» постачальників.
  • Замовник при цьому не отримає результат, але вже витратить гроші.


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


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

Наприклад, ось проект. Була в ТЗ рядок: «Систему треба поставити на моніторинг». Це вилилося в окремий проект: неможливо було ні оцінити трудовитрати, ні спланувати. А замовник все бачив інакше. У нього є внутрішній регламент, історично склався. Далі починаються так звані «терки». З одного боку: «Ми вам зробимо з ТЗ», з іншого — «Ми не приймемо». Зрозуміло, що обидві сторони в тій чи іншій мірі мають рацію, і справу доводити до конфлікту не хочуть: з одного боку, повторюся, суд і «отримаєте, що хотіли», з іншого — витрачені даремно гроші і час. Нікому це не треба.

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

Що робити, якщо зовсім погано

У минулому році мені дістався проект в стані epic fail. Нас попереджали, що замовник, м'яко кажучи, дуже дивний. Точне ТЗ описувалося вже після початку робіт протягом декількох місяців. Загалом, сказати, що складно — нічого не сказати. У кожній сходинці складається ТЗ — питання. Завдання — закінчити проект з мінімізацією втрат.

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

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

Особисті зустрічі і виїзди

Ще одне веселе попадалово — це якщо замовник хоче зустрічатися по кожному чиху. Особливо приємно, коли це нафта з Далекого Сходу. В одному проекті була традиція — яку дрібницю обговорювали раз в тиждень на нараді. Збиралося 12 чоловік від компанії, 5 осіб від виробника заліза і нас троє. І безопаснік. Зрештою, теж змогли побити на частини і перевести на телефонну конференцію. По телефону мужики один одного не бачили, п'ятниці не раділи, і тому наради йшли в 3 рази швидше.

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

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

Залізо

Один раз брали участь у конкурсі на роботи та поставку обладнання, що не виграли. Але компанія-переможець все одно найняла нас на роботи на субпідряд: в країні просто більше не було спеців, тема дуже специфічна. Ну добре, ми не горді, зробимо тільки роботи. За два тижні до здачі з'ясовується, що генпідрядник замовив не те залізо. Точніше, те, але не в тій конфігурації. Ми-то знали, які писати коментарі до замовлення і які конкретно чарівні слова говорити постачальнику. А тут, грубо кажучи, одну букву в моделі переплутали. В Росії такого заліза просто фізично немає. До здачі — 2 тижні.

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

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

Робота з іноземцями

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

Ми відповідаємо за залізо, іноземні колеги ПО. Пропонуємо їм: давайте пропишемо чітко, що входить в склад роботи, де зона відповідальності, зробимо нормальне ТЗ: що робимо, який результат, щоб потім протестувати і штатно здати. Вони: «Та навіщо це треба? Там же ось опис робіт!» — а там документ на дві сторінки в дусі: «Наш професійний інженер приїде і все зробить, не хвилюйтеся». І ще додали: «У нас на сайті є опис системи — ось». Підписалися вони в підсумку без детального ТЗ. Впроваджували як є. Систему вони реально підписали і закінчили тільки через 2 роки (два покоління системи змінилося), спеціально під цього замовника допрацьовували частина функціоналу.

А проблема була в тому, що у них все було заточено під Америку, а в Європі є свої внутрішні стандарти по обробці даних. І в них вони не вклалися. Замовник, природно, стандартну систему не прийняв. Приблизно в цей момент колеги гостро усвідомили, навіщо потрібно точне ТЗ. Точніше, що воно потрібно їм, а не замовника.

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

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

Альтруїзм і відвага

Ще одна риса, напевно, чисто російських проектів — це «Чіп і Дейл поспішають на допомогу». Рідко, але бувають епохальні речі, наприклад, прямо до здачі залізо виходить з ладу. Але альтруїзм і відвага роблять нас непереможними. Там, де іноземний підрядник би махнув рукою і почав би стандартну заміну через вендора, ми можемо і на вуха всіх підняти, і на порозі у їх гендира з'явитися де-небудь у Швеції, або ще гірше — з паяльником залізти в залізяку і полагодити. Звичайно, буває, не допомагає, але в цілому спрацьовує. Правда, гвинтик зайвий завжди залишається.

Регламент замовника

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


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

Але часто ситуація гірша: склад документації не визначений, замовник посилається на ГОСТ. А там, наприклад, три періоду тестування — предприемка, дослідна експлуатація, фінальна здача в промэксплуатацию. У деяких же замовників фінальна здача буває чомусь до дослідної експлуатації, наприклад.

Іноді трапляється, що замовник просто помиляється в ТЗ. Привозимо обладнання, а його ставити нікуди, місця просто немає. Що робити? Знову шукати компроміс.

План приймання

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

Років десять тому було, наприклад, так. Наші інженери здавали систему, документації — мізер, вимог немає. Далекий Схід, наші: «Акти підпишіть, і ми поїдемо». Замовник попався допитливий, але адекватний. Каже: «Ви зараз у вертоліт сядете, а я тут один залишуся з цієї. Давайте по-справжньому перевіримо». Ну, на ходу придумували методику тестування, показували, що і як працює. Підписали. Мало не залишилися гостювати на зайву тиждень.

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

У цілому

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

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

Але треба сказати, якщо б ми пропонували років 10 тому так, як сьогодні працювати, нас би жоден замовник не став слухати. Культури не було, марно. Пам'ятаю, було навіть так в ті дрімучі роки: програму приймання підписали. Дійшло до справи, замовник каже: «Треба інакше». Ми: «Ось документ підписаний вами». Він: «Та викиньте його, нам треба інакше!»
Джерело: Хабрахабр

0 коментарів

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