– как проверить выполнение результата;
– какие ресурсы есть для выполнения задачи;
– зачем вообще нужна задача;
– когда задача должна быть выполнена.
Такая настройка возможна в популярных приложениях JIRA и Redmine (буду благодарен, если читатели в комментариях поделятся своим практическим опытом настройки других таск-менеджеров в формате SMART). Подход с настройкой пяти полей задачи я считаю самым эффективным. Посмотрите на любое рабочее место человека, который делает много похожих активностей (например, кассиры в супермаркетах или операторы колл-центров): у них всегда на видном месте есть удобная пошаговая подсказка в электронном или в бумажном виде. Благодаря этому в сетевых магазинах очередь проходит так быстро, а кассиры при этом не забывают предложить вам собрать 125 наклеек и получить за это сковородку.
Качество постановки задач важно не только для того, чтобы задача была сделана вовремя и с ожидаемым результатом. Это качество влияет на мотивацию специалистов. За время моей работы больше всего расстроенных лиц и нецензурных жалоб от инженеров я видел, когда они в очередной раз получали непонятную задачу. Помните, что команда – ваше всё. Вы же так долго ее собирали (осознали миссию, сформулировали УТП, отобрали интересные проекты, проработали описания вакансий, долго налаживали контакт с лучшими специалистами, нашли уютный офис, купили современное оборудование): будет жалко потерять драгоценного специалиста из-за простой лени или невнимательности при постановки задачи.
Отдельно скажу пару слов про постановку задач специалистам высокого уровня. Константин Андрюнин, соавтор нашего курса для ведущих разработчиков, справедливо отмечает: уровень специалиста определяет уровень доверия к нему, а уровень доверия определяет, насколько абстрактно вы ставите ему задачи». Это очень важный и одновременно очень тонкий момент: вы просто обязаны проявлять доверие к специалистам высокого уровня. Иначе они будут думать, что их считают слабаками, а это – прямая дорога к потере сотрудников.
Вспомните метод Мафии, описанный выше, он как раз про уровень абстракции. Топ-менеджеру надо ставить задачу вида «достичь такой-то прибыли и такой-то рентабельности в таком-то квартале, ибо у нас такая-то стратегия на этот год» и просто отойти в сторонку. Если попросит помощи – дайте. Но ни в коем случае не лезтье в операционное управление. Не справится раз – устройте разбор полетов, второй-третий раз – увольте. Ведущему инженеру на проекте можно поставить задачу вида «проект надо сделать к такому-то сроку, он должен выдерживать такие-то нагрузки и решать такие-то бизнес-задачи». Все. Пусть он дальше сам собирает задачу с заказчика, изучает документацию, распределяет задачи по своей команде, запрашивает дополнительную информацию, обсуждает проект с другими участниками и делает все, что еще нужно для выполнения своей верхнеуровневой задачи.
Еще один занудный регулярный труд по управлению качеством в течение всего проекта – это постоянное управление требованиями. Я бы даже заменил «управление требованиями» на «отклонение требований».
Как обычно происходит: сначала вы продумываете скелет проекта, он обладает минимальным необходимым набором функций и представляет из себя вполне цельный продукт. Но со временем клиенты, консультанты, инвесторы, участники команды и другие люди начинают кидать в общую переписку письма вида «парни, смотрите, что я нашел у наших конкурентов!»… На встречах происходит бурное обсуждение похожих проектов и выдвигается список с десятком новых функций проекта. Еще больший поток потенциальных новинок появляется после запуска бета-версии: клиенты начинают со знанием дела писать письма и давать советы о том, как надо развивать продукт. На эту тему есть прекрасный доклад[22].
В этом вопросе мне очень близка позиция компании 37signals, описанная в их книге Getting Real: лучше меньше, да лучше. Каждый раз, когда вы захотите что-то добавить в свой проект, подумайте:
– какие накладные расходы это повлечет помимо расходов на разработку новинки: обновление документации, обновление процессов, обучение сотрудников и клиентов, закупка оборудования, обновление маркетинговых материалов и т. д. до бесконечности;
– действительно ли это изменение настолько остро необходимо? С какой вероятностью оно окупит все описанные выше инвестиции? Оно востребовано большинством из ваших лучших клиентов? Если нет – забудьте об этом!