ТЗ раздора: как составить, чтобы не было потом мучительно больно

ТЗ раздора: как составить, чтобы не было потом мучительно больно

Сергей Соловьев Менеджер интернет-проекта, Москва

Неточности в техзадании превращают IT-проект в разорительный долгострой. В чем обстоятельства основных неприятностей? Два взора: со подрядчика и стороны заказчика.

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

Клиент уверен в том, что ТЗ должно быть бесплатным, а подрядчик закладывает его в бюджет, к тому же требует задатков . Клиент желает «раз и окончательно», а подрядчик твердит про «итерационную разработку». Получается, что документ, что обязан служить для внесения полной ясности, ускорения и взаимопонимания работы, делается роковым, из-за неосуществимости согласовать ТЗ срывается целый договор.

Вторая крайность, в то время, когда от ТЗ отмахиваются, подписывая вместо него какую-то формальную бумажку. Позже оказывается, что обращение шла о втором функционале, сроках, интеграциях, коммуникациях и процедурах внедрения. Цены, следовательно, также другие, сроки сползают…

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

В чем же неприятность? В большинстве случаев в несложном недопонимании. Само собой разумеется, бывают и открыто мошеннические схемы, но это все же неприятные исключения.

В интересах подрядчика сделать все добросовестно, взять благодарного постоянного клиента, регулярный доход на обслуживании и новые заказы, и хорошие отзывы, быть может, проводить совместные исследования рынка и промо-акции. Клиент с удовольствием оплатит все счета, рассыплется в признательностях и добавит подрядчиков в перечень VIP-персон для поздравлений по праздникам. Он всего лишь желает взять то, за чем обратился – качественное IT-ответ собственных неприятностей.

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

Давайте попытаемся оценить, в чем как раз и как очень сильно различается познание заказчиками и разработчиками IT-ответов подходов к техническому заданию. Собственные вопросы Executive.ru направил обеим сторонам, участвующим в реализации проекта.

Взор со стороны клиентов воображает Илья Маслихин, председатель совета директоров компании Starlit, занимающейся проектированием яхт, судового оборудования и судов.

Илья Маслихин, председатель совета директоров компании Starlit

Точку зрения разработчиков отражают ответы Егора Ермакова, архитектора ответов 1C:PM в компании ITLand, специализирующейся на автоматизации управления проектами и бюджетирования в сфере крупного бизнеса и среднего.

Егор Ермаков, архитектор IT-ответов компании ITLand

Executive.ru: Риторический вопрос. Необходимо ли, по-вашему, ТЗ по большому счету?

Илья Маслихин: Да, само собой разумеется.

Егор Ермаков: Конкретно.

Executive.ru: А чья это территория ответственности? Кто обязан разрабатывать ТЗ?

И.М.: Это такая сложная и важная задача, что в СССР ей занимались особые университеты. Но на данный момент, во-первых, как мне известно, уже нет таких организаций, а основное – бизнес никому не готов делегировать формулирование собственных заинтересованностей. Само собой разумеется, в каждой отрасли имеется большое количество неспециализированных параметров. Но сущность конкурентных преимуществ – в отличиях от рынка. Исходя из этого я, как клиент, осознаю, что обязан активно учавствовать в разработкеТЗ. Но полностью брать ответственность за него достаточно необычно.

В случае если я так прекрасно разбираюсь в IT, что могу самостоятельно расставить все точки над «и», для чего тогда по большому счету нужен IT-подрядчик? Это он обязан готовить ТЗ, а клиент – уточнять и утверждать.

Е.Е.: Принято вычислять, что ТЗ – территория ответственности разработчиков. Но это справедливо лишь для внутреннего пользования – для тиражных продуктов, каковые компания разрабатывает самостоятельно, а позже реализовывает на них лицензии либо онлайн-доступ.

При, в то время, когда проект делается под заказ, необходимо учитывать специфику клиента. Мы не можем предугадать его бизнес-процессы, нужно обследование. Это отдельная работа, которая должна быть выполнена сначала, еще до разработки ТЗ – и тем более до старта проекта. Но, как мне известно, не все клиенты горят жаждой оплачивать подготовку к подготовке к проекту.

А также в случае если разработчик берет все затраты на себя, от клиента нужна, по крайней мере, помощь в формализации, прояснении различных вопросов. Тут также не все двери настежь. «Сваливая» техзадание на разработчика, клиент очень сильно повышает риски проекта. Следует сделать эту часть работы совместно.

В противном случае окажется конфликтная и страшная обстановка.

Executive.ru: Представьте, что партнер ведет себя наилучшим образом, и все двери настежь. Поведайте, что должно происходить в таком совершенном случае. К какому ТЗ необходимо стремиться?

Е.Е.: Имеется два главных подхода к разработке:

  • Каскадный, по методике Waterfall. Тогда сперва выясняют все требования, продолжительно и настойчиво составляют детализированное ТЗ, позже строго по нему разрабатывают, тестируют и внедряют.
  • Эластичный, по методике Agile. Разработка ведется маленькими циклами, по окончании каждого из которых актуализируются требования, критерии, замыслы. Практически, на каждом этапе новое ТЗ.

Так вот, первый способ, каскадный, в целом устарел. На первый взгляд он содержит меньше рисков для клиента, по причине того, что все предусмотрено заблаговременно. А на практике, потому, что сложность информационных совокупностей существенно возросла, это попросту невозможно. Нереально все предусмотреть заблаговременно. Более того, даже в том случае, если разработчик сумеет это сделать по технической части проекта, у самого клиента через некое время поменяются бизнес-процессы, часть функционала понизится по приоритету, появятся новые запросы.

И в случае если подрядчик поведет себя формально – будет всегда цитировать согласованное техзадание, а дальше трава не расти – разумеется, что ни к чему хорошему это не приведет.

Большая часть современных команд разработки стараются убедить клиентов перейти на эластичную методику. Это разрешает обрабатывать все уточнения и новые требования без мельчайшего ущерба для проекта. В конечном итоге, Agile, само собой разумеется, существенно действеннее и экономичнее.

Но тут нужен большой уровень доверия.

Executive.ru: Илья, вы готовы доверить подрядчику разработку по Agile?

И.М.: Давайте уточним, что именно под этим подразумевается. Готов ли я систематично обновлять требования и контролировать, верным ли курсом движется разработка? Непременно. Само собой разумеется, полезно выяснить неспециализированное направление, задать вектор, а позже пошагово его детализировать. Но в случае если под регулярным пересмотром понимается неограниченное постоянный рост и раздувание сроков затрат – какого именно клиента это обрадует?

Меня совершенно верно нет. Тем более что мы разрабатываем проектную документацию в рамках сложных комплексных проектов. К примеру, один из отечественных наибольших клиентов – ВМФ Российской Федерации. В том месте твёрдые сроки, бюджеты согласуются на большом растоянии наверху, и раз в несколько недель заявлять, что «все поменялось» – кроме того не смешно.

Такие варианты не рассматриваются по большому счету.

Некие определенные рамки, так или иначе, должны быть известны сначала. Возможно учесть маржу на доработки, это естественно. Возможно поменять по ходу небольшие подробности, очередность задач, еще чего-то.

Но нельзя допускать бюджета и раздувания сроков.

Executive.ru: Егор, по Agile возможно трудиться в рамках твёрдого бюджета и выполняя четкий замысел-график?

Е.Е.: В принципе да. Лишь, в случае если отправился таковой разговор, также желаю сделать уточнение. Кто как раз возьмет на себя ответственность за эти твёрдые рамки, на каком основании? В случае если речь заходит о техобеспечении проекта в совершенных статических условиях, другими словами о программном обеспечении, пускай кроме того в некоторых случаях о программно-аппаратных системных ответах – разработчик может оценить все с громадной точностью, вправду учесть маржу про запас, и выполнить обязательства сутки в сутки, рубль в рубль.

Либо кроме того стремительнее и дешевле.

Но в случае если подразумевается не только техническая часть, а проект в целом – довольно часто как раз об этом идет обращение, и это главная причина для применения эластичных способов разработки – тогда все значительно сложнее. По причине того, что разработкой дело не исчерпывается, это всего лишь часть проекта. В уравнении много других переменных. Необходимо:

  • Распознать настоящие потребности клиента.
  • Синхронизировать это познание с уже имеющимся программным обеспечением, дабы выполнить интеграцию.
  • Позаботиться о переносе данных.
  • Научить сотрудников клиента.
  • Предусмотреть, как принятые ответы скажутся на работе предприятия на протяжении и по окончании внедрения.
  • Зарезервировать время главных сотрудников клиента на регулярные уточнения требований, причем не по факту происхождения неприятностей, а в любом случае (это особенно принципиально важно, и с этим довольно часто бывают неприятности).

Клиент сам обязан прекрасно поразмыслить, а позже вместе с отечественными аналитиками обсудить, какие конкретно как раз результаты ему необходимы и для чего. Он обязан установить приоритеты и обозначить, в каких диапазонах, по каким обстоятельствам они смогут изменяться. При таком подходе возможно рассчитывать на успех.

Еще раз выделю: разработчик не имеет возможности нести ответственности за непонимание клиентом сути собственных задач. А в то время, когда клиент говорит, что готов сходу назвать все собственные главные требования, это фактически постоянно означает: ожидай беды. По причине того, что бюджеты и сроки должны быть результатом анализа, а не декларироваться.

Executive.ru: Илья, вам имеется что добавить к этому?

И.М.: Анализ требований, время на дискуссию корректировок, выяснение связей – все это звучит достаточно логично. Основное, дабы подрядчик не пробовал спрятаться за прекрасными словами от несложной и принципиальной вещи: он в проекте чтобы помогать отыскать ответ и получать результата, а не дабы обосновать какими-то научными методиками объективную невозможность ответа в начальных рамках.

Так как как довольно часто происходит – на первых встречах о рисках внедрений IT-продуктов практически не упоминается. Это такая мелочь, что не следует кроме того упоминать. А позже, в то время, когда проект уже стартовал, на него выделены ресурсы и частично кроме того израсходованы, внезапно (!) узнается, что потребуются дополнительные работы, задача не хватает четко сформулирована и т.д.

Для чего же вы брались за эту мутную задачу, разрешите задать вопрос? Из-за чего не уточнили все до начала проекта, не предотвратили о том, что бюджет нереален?

Executive.ru: Егор, для чего вы брались, из-за чего не предотвратили заблаговременно? В случае если, само собой разумеется, такие случаи были в вашей практике.

Е.Е.: Формально я имел возможность бы спрятаться за сотрудников, по причине того, что разработчики не обсуждают условий с клиентами, для этого имеется продавцы, руководители и менеджеры проектов. Но тут вопрос достаточно простой. Я больше трех лет руководил отделом разработки и прекрасно осознаю, как оцениваются задачи в часах. В случае если известны задачи, они четко сформулированы – значит, будет не меньше четкая оценка трудоемкости их исполнения.

Конечно, с учетом подводных камней и разных рисков, о которых хороший РП знает заблаговременно, и может сходу их учесть. Тут неприятностей не появляется.

Узкое место, простите, на территории клиента. Это не означает, что я, как разработчик, пробую свалить с себя ответственность, ничего аналогичного. Но и брать чужую ответственность также не могу.

Обращение так как не об игре «поиск виноватого». Мы говорим о том, как добиться результата, нужного клиенту – причем в устраивающих его ограничениях. И довольно часто, кроме объективных ограничений, клиенты создают кроме этого субъективные, совсем лишние.

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

А возможно весьма жестко «настойчиво попросить» создать формы определенного вида, детально прописав, где расположены различные кнопки, как они взаимодействуют и т.д. Клиент уверен, что это то самое лучшее техзадание: все прописано, остается всего лишь сделать. Но обычно в силу ограничений платформы и по вторым обстоятельствам возможно за счет весьма малых модификаций ощутимо победить в скорости. Соответственно, это будет и дешевле. И вот мы спрашиваем клиента: давайте так сделаем, мало вторая форма, но лучше.

Если он говорит: «У нас имеется ТЗ, мы израсходовали на него время, вот так и делайте». Разработчики соглашаются: да, само собой разумеется. Один раз так, второй, третий.

Позже они перестают предлагать улучшения: несложнее без бесед направляться ТЗ. И это всего лишь отчет либо форма. Сейчас перенесите эту проблему на более непростые и ответственные задачи. К примеру, какой-то бизнес-процесс обсудили и прописали в ТЗ. Позже, на протяжении реализации, узнается, что этого не хватает.

Либо имеется конфликт с другими процессами.

Часто бывает, что клиент нежданно вспоминает о чем-то серьёзном. И у нас появляется тот же самый вопрос: что же вы раньше молчали? Неизменно имеется опасность, что маленькие уточнения очень сильно поменяют картину в целом. Запрещено достроить строение до половины, а позже сообщить: «Кстати, давайте увеличим число этажей вдвое. За работу и кирпичи доплатим».

Фундамент не выдержит, потребуется вторая конструкция, вероятно кроме того упрочнение земли. Это не просто дороже, это по большому счету второй проект. Кроме того с нуля начать всю работу может оказаться несложнее и дешевле, чем додавать кое-какие «заодно».

Executive.ru: Итак, уровень качества ТЗ зависит от согласия между разработчиком и заказчиком IT-решения. Это логично. А имеется какие-то приемы, способы для сближения позиций?

Что конкретно вы имеете возможность дать совет друг другу?

Е.Е.: Пожалуй, вот самые серьёзные советы:

  • Не жалейте времени на уточнение терминологии. Большая часть неприятностей возможно решить либо не разрешить им возникнуть, в случае если вещи собственными именами, и осознать друг друга в прямом, буквальном смысле.
  • Клиент обязан осознавать, что разработка ПО – такая же материальная разработка, как строительство либо сборка автомобиля. В случае если что-то забыли учесть заблаговременно, придется это переделать, и, очевидно, переделки поменяют параметры проекта. Желаете обойтись без неожиданностей – учитывайте их в замыслах заблаговременно. Начиная с обследований, и позже в виде корректировок, доработок.
  • Эластичная разработка дает последовательность преимуществ, но дабы ими воспользоваться, необходимы обоюдные упрочнения. Фактически, это по большому счету главный момент: разработка информационной совокупности – не приобретение. Возможно приобрести тиражное ответ по фиксированной цене. А внедрение и разработка по личному заказу критично зависят от нюансов, совладать с которыми возможно лишь совместно, действуя как партнеры.

И.М.: Частично повторюсь, но думаю это принципиально важно: Глубокоуважаемые разработчики:

  • Начинайте собственные презентации с оценки полной цене IT-ответов. Не для протокола, а именно для согласия. Все дополнительные аспекты и те уточнения, о которых вы уже понимаете как фаворит отрасли с обширным опытом – озвучивайте сходу, пожалуйста.
  • Не стесняйтесь переспрашивать клиентов, чтобы получить всю нужную вам данные. Давайте предупреждение о рисках. Звучно, четко рассказываете, в каких случаях не просто вероятны кое-какие затруднения, а по большому счету ничего не окажется.
  • И самое основное – отказывайтесь от тех проектов, каковые вычисляете невыполнимыми. Просто не беритесь за них. Тогда клиент будет искать другого IT-партнера, что справится, или возьмёт веский предлог для радикального пересмотра условий.

Фото: flickr.com, архивы спикеров

Своевременно и в рамках бюджета: Управление проектами по способу критической цепи Альпина Паблишер 2015 Лоуренс Лич Корпоративная совокупность управления проектами: От методологии к практике Альпина Паблишер 2015 Алексей Викторович Ляшук, Дмитрий Геннадьевич Максин, Ренат Ардинатович Нугайбеков IT-менеджмент4333 7

Согласие между подрядчиком и заказчиком при составлении ТЗ

IT-менеджмент26157 69

Как создать техническое задание для автоматизированной совокупности

Жизнь нужно прожить так, дабы не было мучительно больно за бесцельно прожитые годы


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer