Где-то в параллельной Вселенной мирно существуют народы разработчиков. В зеленой долине Девелоперов с идеальной рабочей средой жили сообщества back-end, front-end, mobile-разработчиков и full-stack. Дальше всех в уединении жили embedded. В долину приходили HR-ы и PM-ы, набирая свою команду.
Однажды начинающему PM-у Рокки вручили серьезный проект, и он приступил к задаче со всей ответственностью. В этот раз Project Manager Рокки совмещал ответственность за коммуникацию с клиентом и внутри команды с должностью scrum-master-а.
В команде был хранитель всех знаний о проекте — QA (quality assurance) и ВА (business analytic), который тщательно выявит все требования клиента.
В команде молодого PM-а не хватало последнего важного звена — разработчиков, поэтому Рокки отправился в долину Девелоперов за лучшими программистами.
Путешественника ждала живописная дорога, но он не обращал внимания на пейзажи. Молодой PM был погружен в собственные мысли: к какому народу идти в первую очередь, какие требования выдвигать и что обещать взамен. Ответственность за новый проект так взволновала молодого специалиста, что он не мог систематизировать мысли.
Рокки решил записать вопросы на бумаге, но как только он начал выводить буквы, ветер вырвал листок из рук и унес за зеленые холмы. Порыв был сильным, собирался дождь. Рокки наконец обратил внимание на мир вокруг и поспешно начал искать себе укрытие от непогоды.
По пути вовремя встретилась деревянная беседка, — как только путешественник очутился внутри, стена ливня обрушилась на холмы. Рокки не успел перевести дух, как в укрытие вбежал еще один гость, прикрывая голову от дождя знакомым мокрым листком.
— Не очень-то спасает, но лучше чем ничего — кивнул на импровизированный зонтик мужчина.
На бумаге расплывалось заглавие «Требования для разрабов». Рокки смущенно признался, что это его попытка составить четкие требования для будущих участников команды. Новый собеседник нахмурился.
— Сидеть нам здесь долго, так что расскажу как быть.
Какие бывают разработчики
— Я из народа full-stack и знаю всю кухню изнутри, — представился новый знакомый.
Full-stack — это девелопер, который один способен разработать и фронтенд и бэкенд на одном проекте.
— А поподробнее про бэкенд? И помедленнее, я записываю.
Back-end девелопер — реализует серверную часть приложения, то, с чем взаимодействует клиентская часть, куда идут все запросы базы данных.
Front-end — разрабатывает клиентскую часть приложения, то есть то, что мы видим в браузере и с чем взаимодействуем. Мобильное приложение — это тоже клиентская часть.
Mobile-девелопер — тот же front-end, только клиент пишут не для браузера, а для мобильного устройства.
Embedded — разрабатывают прошивку для различных железок. Это ближе к бэкенду. Много таких специалистов работают в автомобильной индустрии.
На какие суперспособности разработчика полагаться
— Какие разработчики бывают — понятно. А какого специалиста для проекта выбирать?
— Искать нужно специалиста:
С опытом в домене
Каждая доменная область диктует свои правила, например в медицине куча документации и большая сложность в разработке, много тестов. Поэтому специалист, который работал в похожей области, автоматически обладает суперспособностью видеть подводные камни в требованиях и закладывать специфические для области риски.
С грамотным составлением эстимейтов
Эстимейт — когда девелопер говорит за сколько времени выполнит ту или иную задачу, и придерживается установленных сроков.
Того, кто помнит о тестах
Иногда разработчики делают оценку без учетов теста. Поэтому этот вопрос нужно контролировать и закладывать процент на полноценные юниты и интеграционные тесты, ведь на них вполне может уходить столько же времени, сколько и на разработку.
Участие PM в процессе разработки
Собеседник Рокки продолжал делиться опытом.
— Кадры решают все. Доверить найм нужно тому человеку, кто будет работать в этой команде. Лучше Team lead-у, потому что он будет выбирать себе коллег и отвечать за тех кого нанял.
— У меня в команде еще нет такого человека — сказал Рокки.
— Будет! Мотай на ус матчасть и запоминай, что в твоих обязанностях, PM.
- Не нанимать токсичных сотрудников.
Разработчики, как и другие люди не любят коллег с плохими софт-скиллами. Токсичность может выражаться как в постоянном нытье, так и самовлюбленности и надменности. Один человек может серьезно разрушить команду и нарушить таймлайн. Уж лучше приятный в общении средний специалист, чем «рок-стар», не умеющий общаться и доносить свои мысли корректно.
Иногда компания берет специалиста «на вырост» и обучает его нужным скилам внутри команды. Прежде чем брать человека на обучение, убедись, что будет тот, кому не в тягость этим заниматься.
Онбординг — стрессовая ситуация. Специалист приходит в новую компанию и ему нужно познакомиться с десятками процессов: что, где, как, какие доступы понадобятся. Первые недели работы можно облегчить, если вести свою документацию с подробными инструкциями и ответами на частые вопросы. Это не только удобно и экономит время всех участников проекта, но и ускорит процесс онбординга.
Важней всего погода в доме. Общение внутри команды
— Еще один важный момент, который нельзя упустить из внимания — коммуникация внутри команды:
Зарплата — хороший стимул, но ее недостаточно. Важно хвалить девелоперов и давать понять, что они делают что-то важное. Когда человек работает мотивировано — это идет на пользу всем.
- Волшебный вопрос «как дела?»
Иногда коллегу что-то беспокоит и это легко заметить, просто спросив «Как дела? Как настроение?». Может компьютер глючит или митингов слишком много. Бывают ситуации, когда у разработчика росло недовольство и он молчал, потому что никто не интересовался, а заканчивалось все увольнением или сменой проекта.
Разработчики часто страдают синдромом самозванца, и не всегда уверены, что все делают правильно. Поэтому важно давать обратную связь, объясняя, что идет хорошо, а что можно улучшить. Для оценки технической части лучше привлекать технарей, иначе есть риск встретить недопонимание. Если есть сомнения в собственной оценке технической части, запроси фидбек у тимлида. Он сможет проанализировать код/проект и дать свои рекомендации — это тоже будет полезно.
Помогают выявить проблемы в команде и назначить «курс лечения». Лучше решать проблемы в зачатке, чем разбираться с последствиями. На ретроспективах участники команды могут высказать все боли и негатив друг другу. Не нужно их останавливать, этот митинг для этого и предназначен. Это как предохранительный клапан в паровом котле, который не дает ему взорваться.
- Ограниченное количество митингов
Разработчики не в восторге от митингов, особенно когда звонки занимают по полдня. Казалось бы, что сложного? Но девелоперы предпочитают кодить, а не болтать. Во время написания кода или ресерча — они в «состоянии потока». Чрезмерно частая смена деятельности, хоть и вынужденная, может сказаться на качестве работы.
— Ты не хочешь стать моим team lead-ом? Обещаю доверить найм тиммейтов и конструктивную обратную связь, — предложил Рокки.
— Почему бы и нет. Мне еще много чего предстоит тебе рассказать.
Дождь прошел и по мокрой тропинке Рокки с новым team lead-ом отправились в долину Девелоперов.