В последнее время Интернет пестрит статьями ИТ-разработчиков, где они сравнивают работу на аутстаффинге с галерами, жалуясь на профессиональное выгорание. Успех работы на аутстаффинге зависит от многих, на первый взгляд, незначительных нюансов и зачастую зависит не только от разработчика, но и от команды, представления разработчика команде, проект-менеджера, от того, чей заказ нужно выполнить, и от самого заказчика.
В этой статье мне бы хотелось поделиться своим опытом работы на аутстаффинге в качестве и разработчика, и руководителя компании.
Проект-менеджер
Первый, с кем сталкивается разработчик, приступив к работе над проектом - это руководитель проекта, или проект-менеджер. От того, как руководитель проекта выстроит взаимоотношения с разработчиком, зависит и успех проекта, и комфортность разработчика на данном проекте. И здесь проект-менеджеры бывают двух типов:
- всецело погруженные в проект, работающие по методике работы с командой, прислушивающиеся к советам разработчиков, привносящие в проект их предложения, инновации;
- определяет только модули и сроки сдачи.
Тринадцать лет назад мы с партнером также взялись за проект на аутстаффинге. В наши задачи входила разработка внешней и внутренней части проекта. Руководил проектом австралиец. Он ставил нам конкретные задачи, которые мы должны были выполнить к определенному сроку. Например, до конца дня я должен был разработать форму авторизации. Я включал таймер и приступал к работе (делая перерыв на кофе, таймер отключал). Таким образом, я знал, сколько времени уже потратил на работу и сколько у меня осталось до сдачи задания.
В таком формате работы я не видел ни тогда, ни сейчас ничего плохого. Формат достаточно понятный – у тебя есть задача и есть проект-менеджер, который выставляет ее. Если в процессе выполнения задания у меня появляется какая-то идея, я предложу ее решение. Если менеджеру оно не понравится, я буду просто выполнять задачу дальше.
Вскоре я попал на проект с жестким контролем. Проект-менеджер общался с разработчиками три раза в день: утром, в середине дня и вечером. Утром программистам задавались вопросы: что они планируют сделать в течение дня, что они не успели сделать вчера и почему. В середине дня спрашивали, какая работа уже выполнена и будет завершена, а вечером разработчик должен был оценить свою работу за день и поделиться планами на следующий день.
Вопросы задавались не из праздного любопытства. У проекта были жесткие сроки сдачи, поэтому руководитель держал руку на пульсе, чтобы вовремя отреагировать на любую задержку. К ней могут привести различные ситуации. Например, я свою задачу скидываю тестировщику на проверку, а он в это время тестирует другие решения. И только на следующий день выясняется, что мое решение работает с ошибками, нужно исправлять – и, соответственно, задача не закрыта. Ее мне возвращают на доработку, но передо мной уже стоит новая задача, к которой я не могу приступить из-за доработки предыдущей, и, соответственно, сроки сдачи смещаются.
Вот такие нюансы и выясняет проект-менеджер: что успел сделать, как оцениваешь задачу, что тормозит ее реализацию. Я отвечаю, что задачу выполнил, она на тестировании, но, скорее всего, обнаружатся какие-то баги, следовательно, ее мне вернут. Менеджер отмечает, что задачу могут вернуть и нужно время на ее доработку. Это другой формат работы.
И еще на один момент я бы хотел обратить внимание проект-менеджеров. Прежде чем «бросить в омут с головой» вновь прибывшего разработчика, необходим не только онбординг, но и разъяснение условий работы, загрузки, отчетности и т. п.
Разработчик
Наш мир очень гармоничен. На каждый формат работы проект-менеджера найдется свой разработчик. Главное – вовремя его распознать.
Разработчики, как и руководители проектов, бывают хорошими исполнителями, готовыми сутками выполнять поставленные перед ними задачи (главное, чтобы список задач пополнялся ежедневно). Они находят себя на проектах с жестким таймингом. Но есть и такие, кому творческая мысль не дает покоя, и в каждый проект, где бы ни работали, они вносят свою лепту, предлагая собственное видение и решение поставленной задачи. Им комфортней в среде обсуждения и общения руководителя проекта с разработчиками. И здесь главное для проект-менеджера – не пропустить своего разработчика.
Представим такую ситуацию. ИТ-специалист работал в продуктовой команде (компания, которая работает над ИТ-продуктом), где все вопросы обсуждались сообща и главной целью была забота о качестве продукта. Ему предложили поучаствовать в другом проекте, он соглашается. И вот ему выдают техзадание, от которого нельзя отступать, он должен следовать четко по ТЗ и всем необходимым критериям. Отступление от прописанных задач не приветствуется. Понятно, что такая ситуация выводит разработчика из зоны комфорта. Далее, решение о дальнейшем сотрудничестве или прерывание контракта принимает сам разработчик.
Напротив, другой тип разработчиков – постоянно ищущий – охотно идет на разные проекты, где приобретает знания и навыки, учит новые современные библиотеки и технологии. Работая на многих проектах, он становится разносторонним разработчиком: умеет работать с видео, микросервисами, поскольку получил опыт и знания, работая над разработкой интернет-магазина, где было много взаимодействия со сторонним программным обеспечением и интеграции с различными сервисами, знает, как происходит работа с онлайн-оплатой, потому что платежную систему подключал. Соответственно, у него формируется большой багаж знаний. Такие специалисты ради получения новых компетенций готовы работать с любым проект-менеджером.
Аутстаффинг – это философия человека
Как я писал выше, разработчики в основной своей массе – это интроверты, обычные и любознательные. В зависимости от склада характера, от своего внутреннего состояния они и выбирают зачастую свою нишу в разработке. Аутстаффинг позволяет выявить все специфические особенности разработчика, помимо навыков и знаний делает его уверенней в себе и общительнее.
Работа на аутстаффинге позволяет из неуверенного Junior вырасти до Senior. За более чем 12 лет работы через компанию «Фогстрим» прошло много новичков. Растерянные, делающие первые шаги в карьере разработчика, за полтора года работы на аутстаффинге они превращались в специалистов.
Представим себе такую ситуацию: молодой человек решил связать свою жизнь с программированием, окончил курсы или профильный вуз и пришел на работу в продуктовую компанию (компания, которая работает над ИТ-продуктом). Старший разработчик дал ему задачи по его уровню – Junior. Какие-то сложные задачи ему боятся поручать, поскольку он не обладает опытом и знаниями. Вот и выполняет наш герой одну и ту же задачу изо дня в день, из года в год, и при этом у него нет никакого профессионального роста.
Совершенно другая ситуация на аутстаффинге. Если на первом проекте разработчик и чувствует себя неуверенно, ему некомфортно из-за отсутствия каких-то знаний или навыков, но это стимулирует его к изучению необходимого для решения задачи материала. По завершении проекта, а он может продлиться всего два–три месяца, разработчик уже увереннее смотрит на различные задачи. Ко второму проекту он уже приступает без дрожи в коленках.
Между тем, проекты бывают существенно разные. К примеру, в компании «Фогстрим» практикуется предоставление разработчика на проекты не только по его профилю, но и в проекты схожих по направлениям. Если разработчик специализируется, например, на ПО для интернет-магазина, его не будут направлять только на выполнение аналогичных задач, а поручат попробовать себя в разработке, например, приложения для документов, а затем перебросят на приложение для аренды квартир. Таким образом, в течение года разработчик работает на разных проектах, не похожих друг на друга. То есть он пробует себя в разных нишах, в разных технологиях, приобретает опыт и, сам того не замечая, повышает свой уровень экспертизы.
Еще один плюс аутстаффинга – разработчику предлагают проекты не только по его основному направлению и программному языку, но и по вновь изученному. Например, разработчик-Python выучил Golang. Компания находит под новую технологию небольшой проект, где он проверяет себя и свои знания в этом направлении, пока на позиции джуниор, так как язык изучил не давно.
В завершение статьи – небольшой, но важный нюанс. Компании зачастую предпочитают приглашать в штат разработчиков, имеющих опыт работы на аутстаффинге, специалистам одного проекта.
Так что аутстаффинг – это не галеры, а ступенька в профессиональном росте разработчика.
Алексей Романов,
Генеральный директор компании «Фогстрим»