как общаться с подчиненными, чтобы не быть в их глазах мямлей или деспотом;
как грамотно делегировать и что придется в себе искоренять, чтобы это уметь;
почему Scrum все еще передовой фреймворк для разработки проектов и продуктов в digital и как его внедрить в свою команду;
как и с помощью каких инструментов проводить аналитику перед стартом проекта, чтобы в процессе разработки не случалось неприятных сюрпризов;
что такое декомпозиция, зачем она нужна на проекте и как грамотно составлять сметы, чтобы потом не было мучительно больно и стыдно перед заказчиком;
как управлять творческими сотрудниками и креативным процессом без магии, шантажа и подкупа;
как строить команду, чтобы людям хотелось приходить на работу и расти профессионально;
как распределять собственное время менеджера эффективно и при этом не выгореть и не уехать в бессрочный отпуск;
что лучше: собственная команда или аутсорс и как быть с техподдержкой;
как не плодить бюрократию, но при этом четко оформить процесс разработки документально;
как интегрировать сайты и продукты с внешними сервисами и системами без моря слез;
что делать, если все пошло не по плану и случился факап на проекте;
и как, черт побери, понять все то, что ежедневно говорит тебе команда на своем айтишном языке.
Полистайте содержание. Посмотрите главы. Загляните в задания после каждого блока. Если есть сомнения поставьте, где взяли. Не поможет. Особенно, если не планируете постоянно практиковаться. В книге, конечно, есть забавные истории, примеры, кейсы, чек-листы и шаблоны, которые можно брать и сразу применять. Но это инструмент, а им нужно пользоваться!
Часть 1
Картина мира digital-проекта. Тонкости делегирования в IT
Возьмем такую задачку: довести сайт до ума.
Нет, я не пошутил с формулировкой. Таких задач доделать за предыдущими разработчиками на фриланс-биржах пруд пруди. И несчастные сотрудники в них периодически вляпываются. Допустим, вы менеджер, у вас микрокоманда: дизайнер, программист, аналитик, тестировщик. С которыми вы раньше не работали. И есть еще бизнес-заказчик, нешибко разбирающийся в digital-премудростях, но уже почему-то раздраженный. Он эту карусель оплачивает, если его устроит цена и качество. Понятно, что его в первую очередь интересуют деньги и сроки. Ваши действия?
Правильно: бежать!
А что нас смущает? Запредельная степень неопределенности? Тухлая перспектива? Неуверенность в команде? Непонятки с оплатой? Неадекватный заказчик? Поехали, потом заведешься? Гарантированный геморрой при негарантированном результате?
Давайте мысленно представим, как выглядит картина мира digital-проекта и сколько возни тут вырисовывается.
1.1. Картина мира digital-проекта
Итак, в нашей минимальной картине мира сразу получается куча объектов. И с каждым из них много возни и неопределенности. Объекты связаны, влияют друг на друга, за всеми приходится следить и что-то корректировать. Давайте разбираться, пока поверхностно, потом пойдем в дебри.
Заказчик. Бывают два типа заказчиков. Внутренний, когда разработка идет in-house. И внешний, когда проект разрабатывается на заказ.
Заказчик может быть чертовски сложно устроен: не один человек, а группа (с противоречивыми интересами, требованиями к проекту и даже конфликтами). А еще бывают скрытые агенты влияния, например, у заказчика жена, с которой он советуется, и ее мнение в итоге будет определять эстетическую сторону проекта. Но вы об этом не узнаете.
У заказчика определяющая роль. Он формирует концепцию проекта, приоритеты, финансирует весь карнавал. От него зависит все: что бы вы как менеджер ни делали, всегда остается шанс упереться в стенку на той стороне. Именно заказчик определяет степень успешности проекта. Подробнее о работе с заказчиком поговорим в главе 9.
Деньги. Энергия проекта, без них ничего не получится. Даже если это фановые, волонтерские проекты в свободное время или проекты за долю в будущих прибылях. Тогда деньги не присутствуют в явном виде источником может стать сама команда. Классика провала: два друга пилили проект вместе по вечерам, а потом один женился и взял кредит. И все, приоритеты поменялись, разошлись дорожки
Различают два ключевых формата работы. Time & Material оплачивается время, затраченное командой, в таком случае задачи можно менять как угодно. И Fixed Price цена и задачи оговариваются на берегу. У обоих вариантов есть как плюсы, так и минусы. Time & Material переносит риски на заказчика, но работу можно организовать быстрее и гибче. Fixed Price заставляет разработчика зашивать риски и подстраховку в смету, лишает гибкости и снижает скорость выпуска функций из-за процедуры согласования бюджета, но яснее воспринимается клиентом. Существуют также гибридные модели.
Условия заказчика регламентируются тремя способами:
Требования. Постановки задач, технические задания (ТЗ), тикеты[1], рисунки на салфетках, бэклоги Управление требованиями, выявление, уточнение, актуализация, расстановка приоритетов занимают массу времени. Рассмотрим подробно работу с требованиями и способы приоритизации в главе 4.
Юридические документы. Иными словами, бюрократия, более актуальная для заказной разработки. NDA, договоры, приложения, акты и т. д.
Тикет-система. Хранит задачи для команды и статусы по ним. Может быть частью системы управления требованиями или существовать отдельно. Может быть только для внутренних нужд команды, а может пускать заказчика внутрь.
Команда проекта. В digital команда может сжиматься до одного человека, а-ля веб-мастера, и включать в себя заказчика. Либо наоборот: разрастаться, выделяя отдельные функции в роли. Как строить и выращивать команды, мы разберем в главе 7. Командная работа подразумевает делегирование. Например, менеджер справится с задачами аналитика и тестировщика, но с ростом проекта целесообразно выделить это в отдельные роли. Или программист может администрировать серверы, если квалификация соответствует. Но как только серверного хозяйства становится много приходится выносить это в отдельную роль администратора. Для примера будет такая команда:
Менеджер. Ну тут все понятно, это вы. Головой отвечаете за проект, работаете в области высоких энергий и мгновенной ответственности за базар. Про вас вся эта книга.
Разработчик (программист). Бородатый чувак, который пилит код. Пока без дебрей на чем, бэкенд-фронтенд. Универсальный боец.
Дизайнер. Отвечает за весь визуал и интерфейсы. Хотя пошла мода на специализации UI/UX-дизайнеров и т. д. Подробнее об организации дизайна поговорим в главе 6.
Аналитик. Конкретизирует требования. Подробнее об этом поговорим в главе 4, посвященной аналитике.
QA (quality assurance, тестировщик). Тестирует продукт.
Поле власти. Что-то типа электрического поля, к которому подключаются менеджерские инструменты типа «делегирования». Подробнее про власть разберем в главе 2.
Руководство. Ваш непосредственный руководитель и бизнес-заказчик могут быть разными людьми. С одной стороны, у руководства свои требования и интересы, с другой у него есть ресурс, который недоступен вам, но полезен проекту. Власть, опыт, переговорные навыки, право закупать оборудование и софт, менять процессы работы и т. д.
Кто для вас главнее: заказчик или руководитель, и что делать, если у них противоречивые требования? Например, заказчик попросил изменить процесс: нарисовать дизайн до аналитики. Можно ли? Да, если согласуете с руководителем. Приоритет отдавайте руководителю. При этом никто не против, чтобы клиент был счастлив.