Предыстория

Идея этой статьи родилась, пока я писал статью на другую тему: “Product development vs outsourcing”. За мою небольшую карьеру я успел поработать сначала в двух продуктовых компаниях, а затем в двух аутсорсовых. Переход с продуктовой разработки в аутсорс случился два года назад (2018) и показался мне кардинальным. С тех пор я держал в голове мысль написать об этом статью.

Сперва мне показалось, что в продуктовой компании работать лучше. Продуктовой в данном случая я называю банк, который разрабатывал свой веб-сайт, систему мобильного онлайн-банкинг и мобильные приложения. Я тогда думал, что в продуктовой компании работают, по большей части, люди заинтересованные в развитии продукта, тогда как в аутсорсе большинство разработчиков работали по принципу “сегодня один проект, завтра другой, так зачем сильно напрягаться сегодня?”. Не скажу, что я видел какой-то огонь в глазах разработчиков в банке, однако я видел яркое отношение людей к проектам в аутсорсе. Люди в аутсорсовой компании, которые участвовали далеко не в первом проекте, были “расслабленными” и не заботились об архитектуре программного кода. Сейчас я думаю, что именно таким я и видел в целом “температуру по больнице”.

Спустя пару лет и сменив один аутсорс другим гораздо меньших масштабов я понял, что я был не совсем прав: слышал звон, да не знал где он. Я думаю, что…

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

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

Я думаю, что разговоры о проекте в контексте, где таких разговоров быть вроде как не должно, появляются в двух случаях:

• Разработчик хочет решить проблему и научиться чему-то новому.
• Разработчику хочется пожаловаться и выговориться.

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

Чему можно научиться на проекте

На любом проекте каждый может найти что-то, чего он до этого не делал, и это может быть:

• технологии;
• фреймворки;
• алгоритмы;
• инструменты;
• роли на проекте;
• менторство над менее скилловыми тиммейтами.

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

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

Советы

Тимлидам и менеджерам можно дать совет такой: всегда нужно искать тех, кто хочет научиться у вас чему-то новому. Такие разработчики, как минимум, честны с собой и с вами, а значит вы будете уверены в их ожиданиях и мотивации. А если у вас на проекте нечему научиться сильному кандидату, то лучше так и сказать и предложить больше зарплату - авось кандидат и “купит” у вас позицию на этих условиях. Однако это опасно, потому что если привлечь спеца только деньгами, то делать это бесконечно не получится - деньги далеко не бесконечный ресурс. Поэтому необходимо будет после найма искать иные возможности заинтересовать его.

Разработчикам, которые понимают, что у них огонь в глазах на текуем проекте не горит, могу посоветовать только банальные вещи:

• расширить круг своей ответственности;
• менторство над джунами;
• внедрение совершенно новой технологии на проекте;
• роль тимлида нового стрима в рамках текущего проекта или переход на другой проект на роль тимлида;
• pet-проекты.

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