Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

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

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

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

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

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

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

7 <ol><li>Разработчик хочет решить проблему и научиться чему-то новому.</li>

8 <li>Разработчику хочется пожаловаться и выговориться.</li>

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

10 </ol><h2>Чему можно научиться на проекте</h2>

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

12 <ul><li>технологии;</li>

13 <li>фреймворки;</li>

14 <li>алгоритмы;</li>

15 <li>инструменты;</li>

16 <li>роли на проекте;</li>

17 <li>менторство над менее скилловыми тиммейтами.</li>

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

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

20 <h2>Советы тимлидам и менеджерам</h2>

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

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

23 <ul><li>расширить круг своей ответственности;</li>

24 <li>менторство над джунами;</li>

25 <li>внедрение совершенно новой технологии на проекте;</li>

26 <li>роль тимлида нового стрима в рамках текущего проекта или переход на другой проект на роль тимлида;</li>

27 <li>pet-проекты.</li>

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