Широко известный пример неточно поставленного ТЗ
Однажды мне достался проект, рассчитанный на полтора года с ооочень трудным заказчиком. Статус: прошло полгода, но всё ещё идут согласования технического задания. Подписались на одно, но заказчик упорно продолжал выдвигать новые требования. Задача ставилась даже не закончить вовремя или заработать, а выйти достойно, с минимальными для всех потерями.
Было сложно — не то слово. В длинном перелёте я читал ТЗ на 20 страниц. В нём была такая особенность: если читать его бегло, то может показаться, что оно написано правильно и точно. Но если начать копать в детали инженерной реализации, то всплывало сразу много нежданчиков. Некоторые требования подпунктов, вроде 3.2.5 и 4.8.2.9, могли противоречить друг другу или быть просто взаимно невыполнимыми в реальном мире.
В общем, мы с коллегами собрали подборку эпических случаев с ТЗ, которая, возможно, поможет кому-то не повторить наших ошибок. Ну, или повеселит.
Почему нельзя согласовать ТЗ сразу?
Не секрет, что на конкурсах и тендерах крайне редко встречается достаточно полное техническое задание (или хотя бы детальные критерии приёмки, или просто внятные техтребования). Любой размытый пункт документации может обеспечить вам невероятное количество сюрпризов и увеличение работ на порядок. Вот буквально пара примеров из реальных документов, по которым надо было как-то оценивать объём работ и подписываться:
- «Система должна обладать интуитивно-понятным графическим пользовательским интерфейсом», — в переводе на русский, это, скорее всего, означает что-то вроде: «Кроме консоли нужен GUI на русском и с большим количеством пояснений, потому что комплексом будет управлять секретарша». Скорее всего. Потому что может оказаться, что у заказчика есть свои представления об интуиции, и он будет настаивать именно на них. Но чаще всего эта фраза типовая для документации и, в целом, не очень опасная.
- «Система должна обеспечивать простую и гибкую настройку прав доступа пользователя системы», — это уже на порядок хуже. Здесь не описано, какие бывают права, а разница в деталях сетевых ролей может повлиять на архитектуру. И, соответственно, на оборудование, которое нужно в проект.
- Один раз встретилось после детального описания системы документооборота такое: «Срок хранения информации должен быть настраиваемым по периоду», — попробуйте угадать, что заказчик имел в виду. Вас интересует для начала, о какой именно информации речь и где она будет храниться. С равным успехом это может оказаться как обычная фраза о том, что должен быть доступен архив записей (что очень просто), так и то, что это должно быть резервное копирование на отдельную площадку.
Чаще всего, увы, до подачи заявки на конкурс оценить такие подводные камни просто невозможно. В «плохом» случае оценивается средняя вилка возможных отклонений от нашей версии прочтения, и закладывается примерно такое количество работ. Написать по максимуму нельзя: тогда ни в одном конкурсе невозможно выиграть. С другой стороны, если заказчик известный, либо если понятно, что у них уже есть и какие требования в целом, можно примерно прикинуть особенности проекта.
Экологическое равновесие
Естественно, полностью прописать техзадание без специальных (и очень глубоких) знаний в вопросе довольно сложно. У заказчика, как правило, такие знания есть не всегда. Поэтому исполнитель всегда знает, что ТЗ будет дополняться на лету, а заказчик — что исполнитель не будет понимать его. Чем меньше степень дополнений ТЗ и непонимания — тем адекватнее стороны. Но, повторюсь, на больших проектах недопонимание случается почти всегда.
Что же происходит дальше? Дальше наступает интересное экологическое равновесие.
В плохом случае:
- Если, увидев огромное внезапно появившееся ТЗ, исполнитель откажется от контракта госзаказчика по своей инициативе, он может быть добавлен в «чёрный список» поставщиков.
- Заказчик при этом не получит результат, но уже потратит деньги.
В обычном случае, когда «точно по ТЗ» проект явно не заработает:
- Исполнителю нужен контракт для портфолио, для дальнейшей работы с этим заказчиком или просто потому, что нужно сделать работу (для репутации). В этом случае он готов мириться с некими доработками, но ждёт уступок и компромиссов с другой стороны.
- Заказчик понимает, что, если ему сделают точно по ТЗ, сюрпризы могут начаться в обратную сторону, и он, опять же, потеряет время и деньги и получит неработающее решение, которое сам же и более-менее точно описал.
В итоге все всё прекрасно понимают и договариваются. Конечно, бывают отдельные проекты, где крупный заказчик своим ТЗ может буквально свести с ума интегратора. Только он прекрасно понимает, что если так сделает, больше этот интегратор к нему в конкурсы не придёт. А по многим работам в стране всего 2-3 компании, которые вообще могут потянуть такое, чисто по сложности и объёму проекта. Оставаться в конце один на один с последней страшно, уже исполнитель будет условия диктовать.
Например, вот проект. Была в ТЗ строчка: «Систему надо поставить на мониторинг». Это вылилось в отдельный проект: невозможно было ни оценить трудозатраты, ни спланировать. А заказчик всё видел иначе. У него есть внутренний регламент, исторически сложившийся. Дальше начинаются так называемые «тёрки». С одной стороны: «Мы вам сделаем по ТЗ», с другой — «Мы так не примем». Понятно, что обе стороны в той или иной степени правы, и дело доводить до конфликта не хотят: с одной стороны, повторюсь, суд и «получите, что хотели», с другой — потраченные впустую деньги и время. Никому это просто не надо.
В итоге в других частях ТЗ нам пошли на уступки, и мы поняли, какие точно у заказчика требования. На следующие проекты мы — уже проверенный поставщик — и имеем точную базу для расчётов, без вилок.
Что делать, если совсем плохо
В прошлом году мне достался проект в состоянии epic fail. Нас предупреждали, что заказчик, мягко говоря, очень странный. Точное ТЗ описывалось уже после начала работ в течение нескольких месяцев. В общем, сказать, что сложно — ничего не сказать. В каждой строчке составляемого ТЗ — вопросы. Задача — закончить проект с минимизацией потерь.
Сначала я разбил ТЗ на несколько документов. Дело в том, что они согласовывали его всем коллективом руководителей, поскольку опасались ответственности. И каждый раз находили что-то новое. Разбитый на части документ согласовывался по подразделениям, и дело наконец-то пошло. Начали разбираться не «что вы написали», а «что вы хотите». И дальше: «что вы хотите — невозможно и не нужно, давайте лучше вот так» — потихоньку удалось прийти сначала к реализуемым требованиям, а потом и к компромиссу.
Где-то решали быстро, где-то предлагали сдавать по их ТЗ и смотреть, что получится. Заказчик увидел, что работы реально идут, согласился, что так правильно, и не давил, пока всё шевелилось. В общем, вырулили.
Личные встречи и выезды
Ещё одно весёлое попадалово — это если заказчик хочет встречаться по каждому чиху. Особенно приятно, когда это нефтянка с Дальнего Востока. В одном проекте была традиция — любую мелочь обсуждали раз в неделю на совещании. Собиралось 12 человек от компании, 5 человек от производителя железа и нас трое. И безопасник. В конце концов, смогли тоже побить на части и перевести на телефонную конференцию. По телефону мужики друг друга не видели, пятнице не радовались, и потому совещания шли в 3 раза быстрее.
С другой стороны, чтобы понимать человека лучше, в начале надо встречаться, потом можно и удаленно по почте общаться. Это уже проверено на многих проектах.
Опять же, личные встречи нужны, чтобы решать сложные вопросы. Любое серьезное решение или этап — встречаться. По телефону не работает.
Железо
Один раз участвовали в конкурсе на работы и поставку оборудования, не выиграли. Но компания-победитель всё равно наняла нас на работы на субподряд: в стране просто больше не было спецов, тема очень специфическая. Ну хорошо, мы не гордые, сделаем только работы. За две недели до сдачи выясняется, что генподрядчик заказал не то железо. Точнее, то, но не в той конфигурации. Мы-то знали, какие комментарии писать к заказу и какие конкретно волшебные слова говорить поставщику. А здесь, грубо говоря, одну букву в модели перепутали. В России такого железа просто физически нет. До сдачи — 2 недели.
Мы попросили вендора заменить эти платы. И так как и для вендора этот проект был имиджевым, как-никак первая инсталляция такого железа. Нашли и новые платы, и спецсамолет, и спецчеловека, и, вуаля, они оказались у нас даже на 2 дня раньше.
Но, правда, в течение двух недель пришлось попить валерьянку да и пожить по двум тайм-зонам сразу. Днём на объекте контролировать, «тащить», спасать и «выхватывать», а ночью — на почте и телефоне с коллегами из штатов думать, как же привезти столь необходимое для нас железо.
Работа с иностранцами
С иностранными подрядчиками и заказчиками работать тоже «весело». После этого начинаешь любить отечественных сотрудников. В России, может, методологии разработки нет, точнее, обычный водопад: есть задача, к ней документация и фазы. Что такое техзадание знают почти все, пускай где-то лучше, где-то хуже. А иностранцы часто многие этапы просто игнорируют. Даже понятия ТЗ нет — есть «стейтмент оф ворк» или техтребования.
Мы отвечаем за железо, коллеги иностранные — за ПО. Предлагаем им: давайте пропишем чётко, что входит в состав работы, где зона ответственности, сделаем нормальное ТЗ: что делаем, какой результат, чтобы потом протестировать и штатно сдать. Они: «Да зачем это надо? Там же вот описание работ!» — а там документ на две страницы в духе: «Наш профессиональный инженер приедет и всё сделает, не волнуйтесь». И ещё добавили: «У нас на сайте есть описание системы — вот». Подписались они в итоге без детального ТЗ. Внедряли как есть. Систему они реально подписали и закончили только через 2 года (два поколения системы сменилось), специально под этого заказчика дорабатывали часть функционала.
А проблема была в том, что у них всё было заточено под Америку, а в Европе есть свои внутренние стандарты по обработке данных. И в них они не уложились. Заказчик, естественно, стандартную систему не принял. Примерно в этот момент коллеги остро осознали, зачем нужно точное ТЗ. Точнее, что оно нужно им, а не заказчику.
Очень сложно получить с них детализацию по работам. Могут тянуть неделями, рассказывая, что входит в их сервис. Иногда складывается ощущение, что ставят там менеджеру задачу — продать 100 килограмм сервиса в каждый контракт, вот он и пишет без деталей. Потом, конечно, всё это выкидывается, но нервов по дороге портят немало.
На субподрядах ещё смешно было. Они очень любят делать такой финт ушами: мол, основная работа сделана, давайте подпишемся и закроем, остальное там быстренько потом доделаем. В основном же работает. А мы им как генподрядчик: «Нет!» А зачем закрывать, когда не всё работает? В итоге и получается, что русские — вредные. Потому что у иностранцев то квартал заканчивается и бонус должны заплатить, то ещё чего. Мы — им: «Нам вас не жалко». И да, выясняется, что эти мелкие доделки они потом месяцами не могут решить.
Альтруизм и отвага
Ещё одна черта, наверное, чисто российских проектов — это «Чип и Дейл спешат на помощь». Редко, но бывают эпохальные вещи, например, прямо к сдаче железо выходит из строя. Но альтруизм и отвага делают нас непобедимыми. Там, где иностранный подрядчик рукой бы махнул и начал бы стандартную замену через вендора, мы можем и на уши всех поднять, и на пороге у их гендира объявиться где-нибудь в Швеции, или ещё хуже — с паяльником залезть в железку и починить. Конечно, бывает, не помогает, но в целом срабатывает. Правда, винтик лишний всегда остаётся.
Регламент заказчика
Самые сюрпризы начинаются после фразы: «Работы должны быть выполнены или согласованы в соответствии с регламентом заказчика»:
- Регламент могут не приложить к документации конкурса. Ищите сами.
- Регламент может меняться: например, если это требования к инженерке стадионов по европейскому стандарту, может оказаться, что к концу работ европейцы приняли новые требования.
- Была в одном финансовом учреждении служба безопасности, которая даже регламент не показывала. Просто приходил безопасник и говорил: «Так нельзя. Почему — не скажу». И уходил.
- Бывают внутренние требования вроде: «Жить в Москве не менее 10 лет» или «Не привлекать к работам иностранных граждан».
- В банках часто есть целый регламент на основании документов Банка России, их могут и не указать как требования в конкурсе — для них это само собой разумеющееся. Доходит до договора и реализации — появляется вот эта штука со словами: «А вот еще требования к системе». А там разделение прав, администрирование, требования к персоналу по сертификатам.
- Иногда бывают «забытые» требования по бекапам, обучению не менее 10 специалистов и так далее, всё это надо каждый раз выспрашивать.
Часто бывают свои стандарты документирования. Это тоже невероятное попадалово: был проект, когда описание заняло больше времени, чем сами работы. С другой стороны, если заказчик про документацию забывает, надо ему напоминать, иначе они потом поддерживать не смогут. Да и нам же, скорее всего, и поддерживать, поэтому документация обязательно нужна.
Но часто ситуация хуже: состав документации не обозначен, заказчик ссылается на ГОСТ. А там, например, три периода тестирования — предприёмка, опытная эксплуатация, финальная сдача в промэксплуатацию. У некоторых же заказчиков финальная сдача бывает почему-то до опытной эксплуатации, например.
Иногда случается, что заказчик просто ошибается в ТЗ. Привозим оборудование, а его ставить некуда, места просто нет. Что делать? Опять искать компромисс.
План приёмки
Самое главное — не поленитесь и составьте хотя бы простой план приёмки. Методика испытаний — это не лишняя вещь. Написать стоит. На приёмке заказчик часто понимает, что что-то ещё не протестировал и предлагает поменять программу тестирования. Лучше всё сразу предусмотреть. Снимает массу конфликтов и очень помогает в банках.
Лет десять назад было, например, так. Наши инженеры сдавали систему, документации — мизер, требований нет. Дальний Восток, наши: «Акты подпишите, и мы поедем». Заказчик попался дотошный, но адекватный. Говорит: «Вы сейчас в вертолёт сядете, а я тут один останусь с этой. Давайте по-настоящему проверим». Ну, на ходу придумывали методику тестирования, показывали, что и как работает. Подписали. Чуть не остались гостить на лишнюю неделю.
Или вот был случай, сдавали систему. Всё подписали, все счастливы. И тут выясняется, что безопасники не хотят пользоваться так, как айтишники требования написали. Где они были, когда проект писался, непонятно. Мы пошли навстречу, помогли поверх требований, нашли вариант, который всех устраивает. Нам в тот же день пошли на компромисс на другом сложном участке. Так и работает.
В целом
Вообще, ситуация меняется: за последние 8 лет заказчики очень повзрослели, стали серьёзнее относиться к делу. Раньше было вообще без бумаги, даже схему расстановки часто могли не передать. Теперь всё пишется. Мы тоже нахватались грабель, стали сами настаивать, чтобы в проекте была необходимая документация, это ведь и наша защита тоже. Цель — чтобы все всех понимали.
У заказчиков на ключевых должностях появились люди из интеграторов, которые видели процесс с другой стороны. Рынок разросся, за счёт этого культура поднялась. Западные спецы пришли, тоже хорошо понимают, что и зачем.
Но надо сказать, если бы мы предлагали лет 10 назад так, как сегодня работать, нас бы ни один заказчик не стал слушать. Культуры не было, бесполезно. Помню, было даже так в те дремучие годы: программу приёмки подписали. Дошло до дела, заказчик говорит: «Надо иначе». Мы: «Вот документ подписан вами». Он: «Да выкиньте его, нам надо иначе!»
Автор: КРОК
