Киевская конференция и хорошее ТЗ
На этой неделе в Киеве пройдет конференция UA WEB 2008. Я на этой конференции заявлен в качестве докладчика с докладом “Нестабильное состояние проекта”. Обстоятельства сложились так, что я не смог поехать на эту конференцию, тем не менее сверстанная программа конференции интригует.
Вопрос не в тему: Интересно, создатели нашей белорусской конференции “Деловой интернет” смогут приблизиться к той же киевской конференции по качеству интернет-поддержки? В частности сайта…
А еще сегодня я покопал интернет в поисках моей статьи “Что такое хорошее ТЗ на сайт?“. Статья распространилась по интернету. Если не сказать расползлась… Однако, часто статья не подписана, ссылки на сайт автора не стоит, даже ссылки на сайт откуда статья взята (Хабр или Вебмаскон). Прескорбно знаете ли. А еще меня постоянно просят выложить на основе этой статьи обезличенное ТЗ, болванку. Извините, друзья, но такого подарка я делать не буду. Потому как при написании ТЗ надо не бумагу марать, а головой кумекать. А мое доброе дело в итоге породит сотни почти одинаковых документов, а автора никто и не вспомнит и не отблагодарит. 
Ниже мои тезисы доклада для несостоявшегося доклада на киевской конференции.Нестабильное состояние проекта
1. Что такое нестабильное состояние проекта.
Стабильное состояние проекта это когда все идет по плану. Кто-то работает, кто-то опаздывает, кто-то курит, т.е. работа идет как всегда. Но порой что-то случается и все резко меняется: заказчик вспоминает, что через 2 недели сдача проекта и начинает засыпать новыми идеями, команда обнаруживает, что ряд закрытых задач придется переоткрыть… А дедлайн неумолимо наступает. Вот тут-то и приходится переходить на военное положение, включать нестабильное состояние, идти в атаку. Когда все надо успеть с максимальным качеством к конкретному сроку.
2. Когда проект вводится в управляемое нестабильное состояние. Причины.
Когда кажущиеся до этого сроки казались реальными. Когда нужно внести максимальное количество изменений от клиента и поднять производительность команды на 100%. Когда нужно сплотить коллектив. Когда банально надо срочно “причесать” проект. Но никогда не стоит этого делать, когда вы реально не успеваете сдать работу. Нестабильное состояние проекта это не отчаянный шаг в попытке спасти положение, это управляемый процесс.
3. Управляем нестабильным состоянием.
Оперативное управление через таск-борд и митинги с постоянным вовлечением клиента. Выкидываем таск-менеджеры и берем в руки блокнот, планируем и планируем обязательно, отмечаем задачи стикерами, разрисовываем баги майнд-мапами. В этот момент для команды требуется максимальная концентрация. Снимаем все ярлыки и сосредотачиваемся на единой цели: “запустить проект в 23:55 в субботу”. Качество работы будет зависеть от качества всей команды, а вот управляемость от того как поведет себя менеджмент. Менеджер должен настроить коллектив на адаптивный процесс, а сам уехать за ужином для всей команды.
На что это похоже? На Agile. Мы это называем: жестокий Agile.
4. Проблемы.
Проблем может быть много. Неуправляемость, проблемы с контролем качества, с несобранностью команды… проблемы в коммуникациях, воздействия внешних факторов. По сути мы ходим на острие ножа.
5. Мотивация.
Мотивация только одна: победить. Достигнуть цели. Но это не значит, что это напряжение никак не будет оплачено: деньгами, отдыхом и другими благами.
6. Сроки. Когда это закончится.
Как долго может продолжаться нестабильное состояние? Есть опасность перегреть команду, поэтому желательно не превышать 1-2 недели. Это кратковременное напряжение сил, которое используется с максимальной эффективностью.
7. Выход из нестабильного состояния.
Как из отпуска или из запоя из нестабильного состояния проекта надо выходить постепенно. Первое, что требуется дать восстановиться людям, наградить их отдыхом. Первую неделю после напряжения вряд ли кто-то будет работать, поэтому лучше посвятить это время другим полезным занятиям: провести анализ и ретроспективу проведенной работы, демонстрацию достигнутых результатов, устроить банкет.
8. Для чего все это нужно?
Кто-то скажет, что если вы вводите проект в управляемый code&fix, то вы неправильно руководили проектом до этого. Да, легко быть святым сидя на горе Тянь-Шань, гораздо сложнее оставаться святым сидя на базаре. Нестабильная фаза, значительная концентрация команды и очень активная работа с последующим положительным результатом : сплачивает команду, резко повышает доверие в команде, четко показывает кто на что способен, что в итоге повышает уровень всей команды в целом! Положительный стресс положителен для организма.
