Публикация Школы траблшутеров

Разработчик менеджеру не товарищ? Часть 1

Время чтения: 9 мин 25 сек
13 мая 2024 г. Просмотров: 192

Программирование, Проекты | Олег Брагинский, Виталий Лажинцев, Сергей Кондратенко, Павел Куровский

Основатель «Школы траблшутеров» Олег Брагинский со слушателями школы Виталием Лажинцевым, Павлом Куровским и Сергеем Кондратенко рассказывают, как не допускать конфликтов с командой и заказчиками, давая советы и наставления руководителям проектов.

Японская поговорка гласит: «Из-за незабитого гвоздя потеряли подкову, из-за потерянной подковы лишились коня, из-за лишённого коня не доставили приказ, из-за недоставленного приказа проиграли войну». Увы, те же беды есть и в ИТ.

Разработчик пишет код, менеджер управляет проектом. Казалось бы, схема проста и не имеет подводных камней. Однако, взаимодействие может повлиять на развитие и деплой приложения.

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

Понимание ролей

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

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

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

Возникает конфликт мировоззрений детерминированного программиста и вероятностного менеджера. В идеальных условиях дискомфорт делится пополам, в реальности так не случается.

Менеджер поговорил с клиентом, который захотел создать сервис по подбору котят и решил, что для этого нужно добавить в одном из разделов таблицу. Говорит разработчику:

- Друг, нам нужна таблица с котятами!

- Окей, а сколько котят нужно?

- Ну, 5-10, а, может, и 1000.

- Хм, 1000 котят. Сделаем пагинацию, ленивую подгрузку, проверим на разных устройствах и скоростях. Нужен месяц.

При чём детерминированность и вероятность? Стороны диалог вели, но не поняли друг друга: огромна пропасть в исходных данных. Пара десятков или тысяч котят? Менеджер допускает, что клиент хочет добавить 1’000+ животных сразу, либо сделает это со временем.

А что услышал программист? Лимит котят равен 1’000. Разработчик спроектирует приложение под 1’000 малышей, отсюда и сроки. При этом, стоит поменять диалог, и проблема исчезнет сама собой:

- Друг, нужны котята в таблице!

- Окей, сколько?

- От 5 до 10. А если их будет 1000, то насколько дольше делать?

- Ну для 5-10 сделаю за день, а 1’000 – за месяц.

- Много котов пока не нужно, давай для 5-10, а дальше посмотрим.

Есть волшебная фраза, которую обязан озвучить программист: «А это реально нужно? Без этой маленькой фичи разработка будет быстрой, с ней – в N раз дольше».

Тезис может сэкономить и время, и деньги, но чаще всего не звучит. Получается, что программисты плохие? Нет! Как уже писали выше, стороны должны поровну делить дискомфорт.

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

В примере прослеживается очевидное: в большинстве проблем виновата коммуникация. Менеджеры умеют общаться с людьми, программисты предпочитают говорить с машинами. Поэтому диалоги напоминают попытку глухого объяснить немому, как выговаривать твёрдый знак.

Жестокая правда для программистов

Менеджерам без разницы, как реализована фича, важнее техническая возможность, оценка скорости разработки и цены, которые надлежит сообщить клиенту. Разработчик понимает, на каком этапе проект, когда смотрит в код. А как узнать об этом менеджеру, не понимающему инструкций?

Простой и логичный ответ – спросить разработчика. Отсюда вечные вопросы: «На каком этапе?», «Когда сделаешь?», «В чём затык?», «Успеешь до N числа?». Подобный интерес возникает не с целью непрерывного давления, как кажется разработчикам, просто МП искренне не знают.

Их можно и нужно понять, ведь по сути, менеджеру нужно объяснить клиенту, что сейчас для него делается, показать, что было обещано и уже выполнено, либо объяснить, почему не успели.

Но для разработчика подобный интерес выглядит как непрекращающийся прессинг и проверка на устойчивость/компетентность/адекватность (нужное подчеркнуть).

Как разработчику защититься от стресса?

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

Есть ещё одна особенность взаимодействия ролей: жизнь в разном времени. Менеджер пребывает в будущем, разработчик – в настоящем. В цепочку просится тестировщик, обитающий в прошлом.

Чтобы управлять проектом, менеджеру нужно составить план, распределить задачи, сделать так, чтобы люди не остались без работы, если менеджер уйдёт на больничный, в запой или выгорит. Поэтому, пока разработчики делают один модуль, он уже описывает следующий.

Так возникают ситуации, когда каждый пытается перетянуть другого в свой таймлапс:

  • тестировщики дёргают разработчиков в прошлое: «В задаче предыдущей недели нашёл баг…»
  • программисты тянут менеджера в настоящее: «Читаю ТЗ от клиента, и, по-моему, тут какая-то дичь. А зачем…?»
  • менеджеры тянут программистов в будущее: «Посмотри эту штуку и примерно оцени».

Никому из участников процесса не нравится, когда вырывают из зоны комфорта. Есть универсальный и простой совет: «Раз сложностей не избежать, значит, нужно организовать».

Поток

Пытаетесь уснуть, и когда задремали, кто-то постоянно дёргает, спрашивая: «Спишь?». И так по несколько раз за ночь. Только разработчики войдут в состояние потока, их выдёргивают фразой: «Занят?». Главный враг продуктивной работы программиста – регулярный внешний раздражитель.

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

Заканчивается поток завершением плана, удовлетворённостью от работы, хорошим настроением, приближением к деплою. Потревожим разработчика: потеряем поток, будет входить в нужное состояние заново. Отсюда раздражение программиста и недовольство менеджера перфомансом.

Звучит красиво и складно, однако, есть небольшая проблема. Как коммуницировать, если есть шанс сбить программиста с потока? 21 век – социальных сетей! Договоритесь с командой об удобном канале связи и пишите туда: только адресат освободится – глянет и методично ответит.

Делаем усилие для взаимопонимания

Конфликт между разработчиком и менеджером необратим, задача – учиться искать компромиссы, поддерживать и дружить. В первую очередь потому, что команда всегда в одной лодке: потонет один – пойдут ко дну все. Здесь и кроется секрет японской поговорки, приведённой в начале.

Коммуникация – не монолит, подобна конструктору, который команда выстраивает по кирпичику. Чтобы не превращать статью в книгу, многие темы и приёмы не были обозначены. Но некоторые моменты нужно отдельно подчеркнуть. Зачем же всё-таки разработчику «дружить» с менеджером?

Нравится программистам или нет, но МП напрямую влияет на работу первых, зарплату и даже увольнение. Знать, что ценят в разработчиках и как строить с ними продуктивные взаимоотношения – прямой путь к быстрому росту, блестящей карьере и зарплате выше рыночной.

Зачем же тогда менеджеру «дружить» с программистами? Вроде как сам ничего не производит, кроме управленческой функции. Важно помнить, что все достижения – успехи команды. Потому, когда в коллективе есть взаимопонимание и дружественная атмосфера – дело идёт в разы быстрее.

А вообще, все мы ребята хорошие, так что давайте жить дружно! Как говорит Сергей Кондратенко: «Не воспринимай критику от клиента/разраба на личный счёт»!