Программирование, Проекты | Олег Брагинский, Виталий Лажинцев, Сергей Кондратенко, Павел Куровский
Основатель «Школы траблшутеров» Олег Брагинский со слушателями школы Виталием Лажинцевым, Павлом Куровским и Сергеем Кондратенко рассказывают, как не допускать конфликтов с командой и заказчиками, давая советы и наставления руководителям проектов.
Японская поговорка гласит: «Из-за незабитого гвоздя потеряли подкову, из-за потерянной подковы лишились коня, из-за лишённого коня не доставили приказ, из-за недоставленного приказа проиграли войну». Увы, те же беды есть и в ИТ.
Разработчик пишет код, менеджер управляет проектом. Казалось бы, схема проста и не имеет подводных камней. Однако, взаимодействие может повлиять на развитие и деплой приложения.
МП находится «под прессом»: с одной стороны клиент, который не всегда ведёт себя адекватно, с другой стороны – разраб, который может странно отреагировать на задачу или правку. МП тут вообще ни при чём – ему в последнюю очередь нужны конфликты и косые взгляды членов команды.
Понимание ролей
Разработчик пишет код – набор машинных инструкций. Хороша программа, которая алгоритмами предусматривает большинство вероятных сценариев и должным образом на них реагирует.
Программист в синем углу ринга должен создавать чёткие последовательности действий, что формирует особую форму мышления, в которой всё заранее предопределено.
В красном углу находится менеджер, который постоянно общается с людьми различных мнений, знаний, мотивов, которые могут врать, тянуть время, нести чушь, вверять судьбу эзотерике.
Возникает конфликт мировоззрений детерминированного программиста и вероятностного менеджера. В идеальных условиях дискомфорт делится пополам, в реальности так не случается.
Менеджер поговорил с клиентом, который захотел создать сервис по подбору котят и решил, что для этого нужно добавить в одном из разделов таблицу. Говорит разработчику:
- Друг, нам нужна таблица с котятами!
- Окей, а сколько котят нужно?
- Ну, 5-10, а, может, и 1000.
- Хм, 1000 котят. Сделаем пагинацию, ленивую подгрузку, проверим на разных устройствах и скоростях. Нужен месяц.
При чём детерминированность и вероятность? Стороны диалог вели, но не поняли друг друга: огромна пропасть в исходных данных. Пара десятков или тысяч котят? Менеджер допускает, что клиент хочет добавить 1’000+ животных сразу, либо сделает это со временем.
А что услышал программист? Лимит котят равен 1’000. Разработчик спроектирует приложение под 1’000 малышей, отсюда и сроки. При этом, стоит поменять диалог, и проблема исчезнет сама собой:
- Друг, нужны котята в таблице!
- Окей, сколько?
- От 5 до 10. А если их будет 1000, то насколько дольше делать?
- Ну для 5-10 сделаю за день, а 1’000 – за месяц.
- Много котов пока не нужно, давай для 5-10, а дальше посмотрим.
Есть волшебная фраза, которую обязан озвучить программист: «А это реально нужно? Без этой маленькой фичи разработка будет быстрой, с ней – в N раз дольше».
Тезис может сэкономить и время, и деньги, но чаще всего не звучит. Получается, что программисты плохие? Нет! Как уже писали выше, стороны должны поровну делить дискомфорт.
Хороший менеджер должен узнать, из чего состоит эстимейт: оценка времени или усилий для выполнения задачи, а программист должен помогать, подсказывая, что можно выбросить, экономя ресурсы, а где дёшево и сердито сделать с запасом.
В примере прослеживается очевидное: в большинстве проблем виновата коммуникация. Менеджеры умеют общаться с людьми, программисты предпочитают говорить с машинами. Поэтому диалоги напоминают попытку глухого объяснить немому, как выговаривать твёрдый знак.
Жестокая правда для программистов
Менеджерам без разницы, как реализована фича, важнее техническая возможность, оценка скорости разработки и цены, которые надлежит сообщить клиенту. Разработчик понимает, на каком этапе проект, когда смотрит в код. А как узнать об этом менеджеру, не понимающему инструкций?
Простой и логичный ответ – спросить разработчика. Отсюда вечные вопросы: «На каком этапе?», «Когда сделаешь?», «В чём затык?», «Успеешь до N числа?». Подобный интерес возникает не с целью непрерывного давления, как кажется разработчикам, просто МП искренне не знают.
Их можно и нужно понять, ведь по сути, менеджеру нужно объяснить клиенту, что сейчас для него делается, показать, что было обещано и уже выполнено, либо объяснить, почему не успели.
Но для разработчика подобный интерес выглядит как непрекращающийся прессинг и проверка на устойчивость/компетентность/адекватность (нужное подчеркнуть).
Как разработчику защититься от стресса?
Первое: перестать воспринимать вопросы как сомнения в навыках и отвечать прямо. Положил продакшн, нет сил делать или же всё-таки сдержал сроки, как обещал – говорить, как есть. А лучше не дожидаться, когда менеджер забьёт тревогу, и написать первым, чтобы вовремя решить вопрос.
Есть ещё одна особенность взаимодействия ролей: жизнь в разном времени. Менеджер пребывает в будущем, разработчик – в настоящем. В цепочку просится тестировщик, обитающий в прошлом.
Чтобы управлять проектом, менеджеру нужно составить план, распределить задачи, сделать так, чтобы люди не остались без работы, если менеджер уйдёт на больничный, в запой или выгорит. Поэтому, пока разработчики делают один модуль, он уже описывает следующий.
Так возникают ситуации, когда каждый пытается перетянуть другого в свой таймлапс:
- тестировщики дёргают разработчиков в прошлое: «В задаче предыдущей недели нашёл баг…»
- программисты тянут менеджера в настоящее: «Читаю ТЗ от клиента, и, по-моему, тут какая-то дичь. А зачем…?»
- менеджеры тянут программистов в будущее: «Посмотри эту штуку и примерно оцени».
Никому из участников процесса не нравится, когда вырывают из зоны комфорта. Есть универсальный и простой совет: «Раз сложностей не избежать, значит, нужно организовать».
Поток
Пытаетесь уснуть, и когда задремали, кто-то постоянно дёргает, спрашивая: «Спишь?». И так по несколько раз за ночь. Только разработчики войдут в состояние потока, их выдёргивают фразой: «Занят?». Главный враг продуктивной работы программиста – регулярный внешний раздражитель.
Состояние потока длится от десятков минут до пары часов. Начинается с разбора сделанного, вспоминания проекта, настройки на работу. Наступает состояние продуктивности, концентрация и мотивация находятся на пике, что позволяет непринуждённо щёлкать задачи как семечки.
Заканчивается поток завершением плана, удовлетворённостью от работы, хорошим настроением, приближением к деплою. Потревожим разработчика: потеряем поток, будет входить в нужное состояние заново. Отсюда раздражение программиста и недовольство менеджера перфомансом.
Звучит красиво и складно, однако, есть небольшая проблема. Как коммуницировать, если есть шанс сбить программиста с потока? 21 век – социальных сетей! Договоритесь с командой об удобном канале связи и пишите туда: только адресат освободится – глянет и методично ответит.
Делаем усилие для взаимопонимания
Конфликт между разработчиком и менеджером необратим, задача – учиться искать компромиссы, поддерживать и дружить. В первую очередь потому, что команда всегда в одной лодке: потонет один – пойдут ко дну все. Здесь и кроется секрет японской поговорки, приведённой в начале.
Коммуникация – не монолит, подобна конструктору, который команда выстраивает по кирпичику. Чтобы не превращать статью в книгу, многие темы и приёмы не были обозначены. Но некоторые моменты нужно отдельно подчеркнуть. Зачем же всё-таки разработчику «дружить» с менеджером?
Нравится программистам или нет, но МП напрямую влияет на работу первых, зарплату и даже увольнение. Знать, что ценят в разработчиках и как строить с ними продуктивные взаимоотношения – прямой путь к быстрому росту, блестящей карьере и зарплате выше рыночной.
Зачем же тогда менеджеру «дружить» с программистами? Вроде как сам ничего не производит, кроме управленческой функции. Важно помнить, что все достижения – успехи команды. Потому, когда в коллективе есть взаимопонимание и дружественная атмосфера – дело идёт в разы быстрее.
А вообще, все мы ребята хорошие, так что давайте жить дружно! Как говорит Сергей Кондратенко: «Не воспринимай критику от клиента/разраба на личный счёт»!