Анализ

Стоит ли готовить техническое задание своими силами?

0

Мне уже не раз встречались проекты по подготовке технического задания – это отдельный этап перед большим тендером на внедрение IT систем (ориентировочный бюджет более миллиона долларов).

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

Как вы оцениваете такой ход заказчика как outsource задачи подготовки ТЗ? Какие проблемы вы видите в этом? Какие преимущества?

Критичность закрытия фаз/итераций. Пример из практики

0

Очень важно в крупных корпоративных проектах закрывать фазы (этапа, итерации) согласованием пакета закрывающих документов.

 

Сам факт закрытия фазы позволяет:

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

Из практики отечественных проектов встречались ситуации когда в проекте на этапе зависли на согласовании несколько аналитических документов. Казалось бы согласованным в документах было около 80%. Команда проекта решила что необходимо двигаться к разработке и по ходе решить оставшиеся 20% требований. Однако в течении нескольких последующих месяцев это привело к тому что

  • аналитический документ и зменился более чем на половину
  • объем работ вырос в полтора раза
  • было потеряно около трети времени на разработку в следствии кардинального изменения
  • существенно изменились сроки проекта
  • поставщик понес убытки на потерянном объеме работ
  • клиент был недоволен что “его по-прежнему не пониманию и делают всякую ерунду”
  • клиент наблюдая податливость в протягивании согласования аналитического документа позволял себе “пропихивать” новые изменения и расширять рамки проекта

Используйте макеты, быстрые прототипы – скетчи. Пример на миллионы:

0

Несколько десятков лет назад компания IBM решила создать голосовой интерфейс управления компьютером. Огромное число пользователей мечтало приказывать операционной системе, а не тыкать в нее мышью. Проект чуть былоне запустили,но решили проверить, а на самом ли деле пользователям это понравится? Скетч был простой.Приводили пользователя и сажали егоза компьютер. Пользователь вдохновенно отдавал команды, в другой комнате сидел человек, который эти команды слышал и выполнял. Пользователь видел процесс и результат выполнения команды на своем мониторе.

Гениально!

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

Go to Top