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

Удобно ли расписание сеансов? Вовремя ли начался фильм? Как много было рекламы? Насколько комфортны кресла? А какое качество звука? Повезло ли с соседями – или опять чавкали и шелестели чипсами?

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

Как обычно происходит оценка проекта в IT?

ТЗ от клиента дают на осмотр специалисту / старшему специалисту / руководителю проектов. Он прикидывает объем трудозатрат "за всех" и сообщает менеджеру грубую оценку. Менеджер накидывает на эту стоимость некий фирменный коэффициент и получает сумму, которую озвучивает клиенту.

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

Правильный подход к оценке должен состоять из следующих этапов.

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

В мире накоплено немало знаний о том, как вести проекты. Разработаны ГОСТы, стандарты, методологии и целые идеологии, которые говорят нам, что нужно сделать, чтобы прийти от идеи к результату. Нам остается только выбрать рекомендуемый путь и следовать ему.

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

Этот инструмент в широких кругах называется ТЗ – техническое задание. Еще он может называться спецификацией, user story, заданием или требованиями к разработке, суть одна – этот документ помогает нам прийти из точки A в точку B. Именно с такой позиции мы будем его рассматривать, независимо от формализации.

Но довольно банальностей! Перейдем к мясу.

Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса.

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

Знаю-знаю, вы – крутой программист и тут же возразите мне – а что же, я должен предвидеть все, что нужно бизнесу? Должен догадаться, чего хочет заказчик? Бесконечно реализовывать его странные хотелки?

А имеете ли вы моральное право задавать такие вопросы? Проверьте, что из этого списка вы сделали для этого:

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

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