На днях друг хвастался мне, что завернул на собесе чувака, который работал только в аутстафах. Друг работает в продуктовой компании и твердо убежден — от придурков с галер нет никакой пользы. Там работают бездушные наемники, профессиональные проходимцы собеседований и лентяи. Говорит, продукт загнется раньше, чем они подберут себе цветовую тему в IDE.
Мой друг категоричен, и ненавидит аутстафы даже больше, чем они заслуживают. Он считает, аутстафы убивают саму суть разработки. Берут плохих разрабов, натаскивают проходить собесы, продают подороже в корпорации, где все устаканено, и вопрос выживания вообще не стоит, и просто живут спокойно на попиле денег и имитации работы. В общем, ненавидит их как трудяга-коммунист биржевых брокеров.
А я всю жизнь работал в аутстафах, и, конечно же, считаю по-другому. И я хотел осудить друга, но вспомнил как сам отказывался брать продуктовых разрабов на собеседованиях.
Однажды мы с командой проводили тех-интервью, кандидат неплохо шарил, но мы решили, что он нам не подходит только потому, что пришел из продуктовой компании. Парень полчаса тер про продукт, который делал на прошлой работе. Он рассказывал не как продукт сделан, а что продукт делает для людей. У нас спрашивал, что мы делаем, а не как и с помощью чего. Мы, конечно не говорили друг другу: «Ему важен продукт, а должно быть насрать», но были единодушны в своем нежелании работать с ним, и навыдумывали много поводов для отказа.
Я тогда не придал этому значения, а сейчас понял — похоже, разработчики, которых по три раза за год продают на чужие проекты, и разработчики, которые пять лет фигачат один продукт — совсем разные профессионалы. Обстоятельно покопавшись в себе, я понял, что не просто отношу себя к первым, но и подсознательно презираю людей, которые больше двух лет работают над одним проектом.
Возможно, этому виной плохие примеры. Одна продуктовая фирма, где я работал, использовала C# 2.0. ДВА НОЛЬ. Аргументировали они просто: проект большой, если переносить его на новую версию, наплодим кучу багов. И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.
Есть тысяча карьерных причин для того, чтобы использовать новейшие технологии. Сознательный спуск карьеры в унитаз я еще могу понять — окей, человек нашел себе работу на всю жизнь, это его выбор. Но черт подери, у тебя есть задача, вот тебе фишка из C# 4.0, которая ее автоматизирует. А они отвечают: «Нет, мне не нужна автоматизация. Сейчас я начну писать тонну говнокода, и все заработает». Они говорят мне в лицо, что не верят в новую технологию, не верят, что она улучшит их продукт. И ведь она реально не улучшит. Яма не станет лучше от того, что ее выкопали экскаватором вместо лопаты. Но для меня эти разрабы, как таксисты, которые ненавидят Яндекс, и приходят в ярость от разговоров про автопилоты. И с такими разработчиками я работать не готов.
Очевидно, что это крайний кейс. Большинство продуктовых команд используют довольно новые технологии, но здесь очень показательны акценты. Что для этих разработчиков самое важное? А что самое важное для меня? Очень разные вещи.
Для них я хипстер, что режет хлеб слайсами. Человек, который уничтожит результаты трехлетней работы ради новенькой технологии. В их системе ценностей, я вредитель. Мой подход, моя манера писать код для них — трата времени. То, что для меня состояние проекта в джире важнее его состояния в реальности, для них немыслимо.
Вообще, я уверен, ребята из продуктовых компаний могут гораздо лучше меня рассказать, почему я и такие как я — сплошь бесполезные дураки, да и я в принципе не готов с ними спорить. Мы делаем разные вещи, по разным мотивам.
Им важно, что делать и для чего. Мне — хоть мозги для умных унитазов, хоть оружие геноцида — главное, как мы это реализуем. Нас объединяет только то, что все мы пишем код.
Но недавно я нашел работу мечты, которая поставила под сомнение все, о чем я написал. Меня позвали делать роботов, делать их на моем любимом стеке, в стартапном темпе и с очень крутой командой. Это была работа в самой что ни на есть продуктовой команде, и я страшно радовался.
Каждый день на этой работе я чувствовал себя обманщиком — я не тот парень, что им нужен. Пока я три недели перепиливал архитектуру какого-то незначимого модуля, они сделали всю настоящую работу. А потом еще и хвалили меня, из вежливости, мол, отличная архитектура, Фил. Правда она нам нахер не нужна, и ты просто жрешь бюджет на никому не нужный перфекционизм, но все равно спасибо, что так красиво заврапал наши логгеры.
Мы быстро разошлись, и я очень надеюсь, что не потратил слишком много их времени и денег, потому что после мне было очень стыдно. Но моя ошибка не в том, что я неправильный разработчик — она в том, что я неправильно понимал, какой я разработчик. И самое главное — я не готов меняться. Я разраб для аутстафов, гребец с галеры.
Когда меня нанимают, то покупают мою способность проходить собеседования, потому что мой работодатель уже на следующий день будет продавать меня корпорациям. Важный аутстафный скилл — я очень хорошо умею быть тем человеком, который нужен команде. Им нужен парень, который на каждый чих рассылает десятки имейлов с вопросами? Базару ноль, будут вам имейлы. Нужен агрессивный кодревьювер? Подержите мое пиво. Команда нуждается во внимательном менторе? Присаживайтесь поудобнее, я вам сейчас все расскажу за дотнет и системы типов. Нужно делать фичи в бешенном темпе? Я машина, которая будет фигачить код днем и ночью, пока аджайловый график фич не придет в нужное состояние. Делать все то же самое в продуктовой фирме я не могу. Мои проектные личности живут очень недолго, и уже через три месяца мозг требует перемен. Я начинаю выгорать и писать слезливые статьи.
Ирония в том, что меня продают в продуктовые компании. Но приходя на новый проект из аутстафа, ты хозяин положения. Если не нравится, тебе даже не нужно увольняться — просто просишь другой. Люди, которые нас нанимают, слишком заняты идеей, что нас нужно использовать на всю катушку, у них просто нет времени обучать нас предметной области и философии проекта. Они гораздо более организованы, чем менеджеры в обычной продуктовой конторе, потому что при работе с аутстафом связь между влитым баблом и количеством закрытых тикетов очень явная.
Их организованность приводит к очень грамотному описанию задач и налаженному процессу разработки. Они закладываются на текучку кадров, поэтому качество кода имеет для них огромное значение. Так ты можешь хорошо работать, не вникая в бизнес природу проекта. На мой взгляд, такие условия — лучшие для разработчика-профессионала.
Продукт в аутстафе мимолетен, подход вечен. Я продаю и развиваю свой подход. Если бы на ту работу мечты я пришел не как штатный сотрудник, а как чел из аутстафа, думаю, у нас все сложилось бы лучше.
Есть очень много проектов, над которыми я бы хотел поработать. Счастливчики, которые работают над ними сейчас, скажут себе перед смертью: «Я делал VSCode, это имеет огромное значение для человечества», и будут правы. Я скажу себе: «Я писал отличный код на каких-то проектах, это имеет огромное значение для меня», и буду прав. Главное, быстро и верно выяснить, что тебя радует.
Комментарии (150)
Vasily_T
21.05.2019 17:24+12Вот жеж, никогда не думал что существуют люди которые делят разработчиков по таким критериям…
puyol_dev2
21.05.2019 21:31+1Автор пишет буковки для компилятора, называя это «кодом». И не понимает зачем это нужно. Лично я понимаю людей, которые работают ради заработка или чтобы помочь другим людям. Но не понимаю тех, кто пишет буковки для компилятора и считает это смыслом
Whuthering
22.05.2019 00:48Возможность красиво и эффективно решить поставленные _технические_ задачи, например. А для чего практического нужны эти технические задачи, меня уже не особо интересует.
White_Scorpion
22.05.2019 10:28Кто это увидит кроме разраба? Мало того — кто это увидит, хоть кто нибудь кроме того, кто полезет именно в конкретный модуль?
У кода есть цель. Я конечно понимаю, что "эффективные манагеры" могут превратить изначальную цель "сделать людям лучше" в фикцию, но сейчас не о них речь. Сейчас речь о человеке, который вместо того, чтобы решать поставленную задачу — вылизывает код. Да он будет стилистически идеальным, но… какой смысл?
Это, простите, какая-то кодомастурбация — получать оргазм, если код идеальный. Я в принципе признаю за людьми право на извращения — у всех свои слабости — главное чтобы это не становилось манией, что уже опасно.
Даже умные мозги для унитаза должны делать то, что этому унитазу положено (не знаю никогда не сталкивался с умными унитазами) — т.е. у них (мозгов) есть цель. Т.е. даже у умного унитаза — есть цель. А тут некий разработчик говорит нам, что цель не важна.
Whuthering
22.05.2019 11:29+3Кто это увидит кроме разраба? Мало того — кто это увидит, хоть кто нибудь кроме того, кто полезет именно в конкретный модуль?
А зачем это кому-то видеть?
Недавно один мужик рассказывал, что у японцев часто бывало, что самый красивый орнамент или узор на кимоно скрыт под слоями ткани, и его не видит вообще никто, и только хозяин знает, что он там есть.
Вот тут точно так же — какая разница, посмотрит кто в код или не посмотрит, главное, что я его правильно спроектировал, грамотно написал, решил в процессе этого сложные инженерные задачи, и теперь он работает стабильно и эффективно. Ну и раз он работает стабильно, эффективно, и в соответствии с ТЗ, то логично, что он решает поставленную задачу.
Это как произведение искусства — кто-то их делает, чтобы ими любовались и восторгались, кто-то их делает чтобы заработать денег, а кто-то их делает ради самого творческого процесса и удовольствия от совершенства и завершенности работы.
Кто-то рыбалкой занимается ради пропитания, а кто-то ради удовольствия.
Кто-то на джипах ездит в говны чтобы добраться до соседней деревни, а кому-то просто нравится ездить по говнам.
А если за любимое дело еще и платят хорошо — то вообще отлично.
Моё хобби — программировать, а не решать проблемы бизнеса. Но если результат моего хобби решает проблемы какого-то бизнеса, тем лучше и мне, и бизнесу, и мы договоримся на взаимовыгодных условиях.White_Scorpion
22.05.2019 12:55-1У хобби есть результат — получение удовольствия, расслабление, отдых.
За код же нам — платят. Т.е. заказчик заказывает конкретное ему нужное решение. Это решение мало кто видит, но заказчик обычно платит за две вещи:
- За, собственно, решение
- И предоставление этого решения за указанный срок — чтобы надобность в решении не истекла
И если эти два условия выполняются — то никаких проблем.
В статье же я увидел — код ради кода. Ничего не скажу против того, что красиво написанный код — приятно читать. Это факт — приятно. Но если сравнить "быстро внедрённое решение" приносящее в результате доход, удовлетворение от выполненной задачи или возможность перейти на новые задачи и стать выше уровнем со 125-тью возможностями красиво написать "Hello, world!" на 15 различных языках и фреймворках и все они будут одинаково прекрасны — то… "Hello, world!" — бесполезен.
К тому ж эпопея с "Hello, world!" нарушает основной принцип программирования — KIS.dimm_ddr
22.05.2019 13:19+3Если человек умеет писать код ради кода так, чтобы получалось решение удовлетворяющее заказчика за разумное для заказчика время, то разве так уж важно что разработчик при этом пишет код ради кода и его совершенно не волнует продукт и его судьба? Пока всех все устраивает нет никакой проблемы — один решает свои мысленные задачки создавая идеальный в его понимании код в условиях ограниченных ресурсов, другой платит деньги и получает работающий результат. Кому плохо то?
White_Scorpion
22.05.2019 14:12+1Если человек пишет код красиво сразу или имеет время на его облагораживание (что случается реже) — это прекрасно.
Но в статье я увидел посыл: задача ничто, код — всё. А эта позиция — ущербна как любая граничная. Баланс он где-то посерединке.
Вышел новый фреймворк? Давайте перепишем проект на Asp.NET MVC под Angular? Плевать что послезавтра релиз, плевать, что большинство команды знает Angular только по названию — внедряем и переписываем! Это путь в бесконечный процесс, за которым… Да даже в резюме нечего написать. Ведь одно дело — перечень решённых задач, а другое — прекрасно выглядящий код, который тем не менее не делает ничего ибо не закончен.
Сколько проектов не вышло, сколько команд распалось из-за того, что хотели сделать "сразу как надо" и облагораживали решение, а в это время конкуренты быстро выпускали продукт и допиливали в процессе?dimm_ddr
22.05.2019 15:07+1Конечно нужен баланс, я не спорю. Я скорее о том, что если у автора при его позиции про «код — всё» получается завершать задачи, то вполне нормальная у него позиция. Это же разные вещи, хоть и связанные — отношение к задаче и умение задачу завершать. И автор там в какой-то момент пишет что завершать задачу и клепать готовые фичи он умеет.
mkovalevskyi
22.05.2019 18:20Зато, вы будете уникальны, ибо после этого переписывания уже никто ничего не будет понимать в коде )
Типичный индусский подход, для секьюретизации рабочего места.
dustd
22.05.2019 22:25Вы сейчас путаете теплое с мягким. Давайте посмотрим на это со стороны… Ну хотя бы Product Owner`а — итак, что нам надо: продукт, который будет приносить людям радость, а люди за эту радость будут платить. Желательно получить этот продукт как можно быстрее и как можно дешевле. При этом все задачи на проекте, как правило, делятся на 2 категории: на подумать и на запилить. При этом задачи «на подумать» — это не просто бейн-сторм нон-стоп. Это эксперименты, неудачи, поиски. Для этого хороши именно продуктовые программеры. Задачи на «запилить» — четко регламентированные, хорошо описанные, и, в большинстве случаев, абсолютно тупые. От забора и до обеда. Думать не надо. Нужно просто писать код. Хороший, легко читаемый и легко поддерживаемый код. И вот тут себя галерные рабы покажут гораздо лучше. Поскольку будут и эффективнее и дешевле. В итоге, хороший PO будет совмещать.
White_Scorpion
22.05.2019 22:58Не сможет, потому что в (по статье) команду не нанимают людей с альтернативной точкой зрения на продукт. Фанаты кодо- и фреймодрочерства — просто не примут человека с иным мышлением.
dustd
23.05.2019 09:22А причем тут вообще фанаты фреймо- и кододрочерства? Я, как лид, ПМ, ПО и тот человек, который отвечает за продукт перед бизнесом (и фреймо-кододрочер по совместительству) должен прекрасно понимать, когда можно менять инструментарий, когда это сделать категорически нужно, а когда категорически нельзя идти на поводу таких товарищей. Вы взяли на работу людей, которые не в состоянии работать над продуктом, потому что занимаются фигней и исключительно сменой стека — это ваши проблемы. Вы отдали что-то аутстаферу, не написав должным образом ТЗ (в котором должен быть указан стек), Code Style и Code Convenction? Это снова ваши проблемы. Кстати, автор кододрочерами называет именно аутстаферов, а не продуктовиков… И у аутстафера не должно быть НИКАКОЙ точки зрения на продукт. Ему, с точки зрения ПМ`а и ПО`ра, думать вообще вредно.
White_Scorpion
23.05.2019 11:20У аутстафера — действительно не может быть никакой точки зрения на продукт, просто потому что ваш продукт — это не его продукт. Его продукт — это та часть работы, что ему поручена. Теперь представим ситуацию вы вычленили часть работы, что можно выполнить вне контекста, составили ТЗ, согласовали и аутстафер начал выполнять-выполнять-выполнять… Один фреймворк, смена версии языка, новый паттерн архитектурный. Это вместо того, чтобы написать, оттестировать, рефакторнуть и сдать работу.
Допускаю, что с вашей точки зрения это может быть приемлемым — ведь интерфейс соблюдается, а у вас дофига времени. Но как часто в бизнесе бывает дофига времени? А если учесть, что оплата у аутстафера может быть почасовая — за его эксперименты и обучение платите вы.
Выбирать то в любом случае вам, как тому, кто платит.
dustd
23.05.2019 14:38Вы все исключительно верно написали. Оплата аутстаферов — как правило посуточная. Моя задача — выжать его за эти сутки по максимуму. Вы думаете, я оставлю ему время на эксперименты с фреймворками? Я оцениваю время на задачу, согласовываю с ним — все, арбайтен. Задачи для аутстафера в принципе не должны превышать 4 часа.
0xd34df00d
23.05.2019 16:15Баланс он где-то посерединке.
Например, можно искать задачи под интересующий стек, а не стек под интересующие задачи.
Если совсем повезёт, то интересующий стек и будет задачами, но этого дзена лично я пока не достиг.
areht
23.05.2019 06:00> заказчик заказывает конкретное ему нужное решение.
Заказчик обычно даже не знает что ему нужно. Он, иногда, знает как оно должно выглядеть. Мысль, например, о том, что код должен быть поддерживаемым, а не написанным на скорость, приходит потом и не всем. Он такой, может, и не всегда нужен, но этого заказчик тоже не понимает.
И, внезапно, быстро внедренное решение оказывается несовместимым с реальностью, вместо дохода приносит остановку бизнеса и необходимость срочных доработок.
В общем, за заказчика ТЗ додумывать надо. А то этот бедолага разориться раньше, чем осознает и научится. А тогда он с повторными заказами не придет.White_Scorpion
23.05.2019 08:35Ну это уж проблема постановки и интерпретации задач, но никак не идеальности и чистоты кода. И для того, чтобы постановка и интерпретация задач была нормальной с заказчиком должны работать совсем другие люди, которые код — писали когда-то в далёкой юности, но вместе с тем знают азы его написания, иначе вообще не команда а фигня какая-то (утрирую, конечно).
areht
23.05.2019 08:54а в каких единицах у вас в постановке степень необходимой чистоты кода указывается?
White_Scorpion
23.05.2019 09:55Чисто субъективно — лично я считаю тот код чистым который удовлетворяет условию:
- Делает то что нужно
- Легко читается и понимается
- От взгляда на него — не хочется найти и убить предыдущего писателя.
areht
23.05.2019 11:461) это не про чистоту
2) Легко читается и понимается ВАМИ, субъективно
3) то есть, пока код только ваш — он идеален :)
В общем, вы сами решаете какой код писатьWhite_Scorpion
23.05.2019 14:04- Какой смысл в красивом коде, если он ничего не делает? Сам смысл кода — это красивое и элегантное (по возможности) решение задачи.
- Да это субъективное понятие
- Нет. Я не пишу идеальный код. Ииногда даже костылю, увы. Но и не лицемерю на эту тему. Понятие красоты — действительно у каждого своё.
Да я решаю. И вы — если вы программист. И любой другой программист решает. Главное следовать одному незыблемому правилу — "не делать из
едыкода культа" О.Бендер :).De-Korg
23.05.2019 16:07Понятие красоты — действительно у каждого своё.
— нет, красота это симметрия, она нравится любому человеческому мозгу т.к. ее проще запомнить и легче воспринимать, т.к образы стуктурны и воспроизводятся отражением, нужно в разы меньше усилий
т.о. это объективное понятиеWhite_Scorpion
23.05.2019 16:23Не соглашусь. Стандарты красоты у всех разные и зависят как от человека так и от культурных традиций: кто-то получает эстетическое удовольствие от созерцания абстракионизма, а кто-то — называет абстракционизм мазнёй.
На небольшом острове Тонга красотой считаются большие физические размеры. Причём настолько что у первых "красавиц" острова — трудности с передвижением. Я считаю такую "красоту" — сомнительной.
areht
23.05.2019 18:26> 1. Делает то что нужно
vs
> 1. Какой смысл в красивом коде, если он ничего не делает? Сам смысл кода — это красивое и элегантное (по возможности) решение задачи.
что-то вы сами с собой спорить начали
вы делаете элегантное, на сколько считаете нужным, автор делает на сколько считаете нужным. Почему вы делаете как надо, а автору приписываете культ?White_Scorpion
24.05.2019 00:43Противоречия нет, ключевое — решение задачи. Если оно красивое и элегантное то — это прекрасно. Если не очень, но есть время на приведение в красивость и элегантность — тоже хорошо.
areht
24.05.2019 02:19решение задачи != чистый код
чистый код != решение задачи
ничего не делает != !(делает то, что нужно)
И решать задачу может не только грязный, но даже обфусцированный код.White_Scorpion
24.05.2019 10:20Логично. И что?
Т.е. вы спросили меня какой код я считаю чистым? Я — привёл пример субъективных критериев — и теперь что вы пытаетесь мне доказать? Что критерии субъективны? Так это факт — ибо они мои. Кому-то и говнокод — вполне себе код. Главное что задача решена.
Я считаю, что код — облагораживать надо, но не возвожу облагораживание кода в абсолют. Также моё мнение, что не стоит прыгать с фреймворка на фреймворк, если до релиза рукой подать, а новый фреймворк может преподнести незапланированный сюрприз.areht
24.05.2019 11:14> Т.е. вы спросили меня какой код я считаю чистым?
И получил ответ «Главное что задача решена.». Я не то, что бы пытаюсь убедить, но это не ответ на мой вопрос. Нет у вас ответа лучше — чтож…
0xd34df00d
23.05.2019 16:14+1Это, простите, какая-то кодомастурбация — получать оргазм, если код идеальный. Я в принципе признаю за людьми право на извращения — у всех свои слабости
Вы так говорите, как будто это что-то плохое.
И как будто получать оргазм от мифической полезности людям сильно лучше. Тем более, что, ага, полезность — все тут вакцины от рака делают, или библиотеки для вакцин от рака, или хотя бы библиотеки линейной алгебры, которые в итоге будут лежать где-то внизу технологического стека поиска вакцины от рака.
Т.е. даже у умного унитаза — есть цель. А тут некий разработчик говорит нам, что цель не важна.
Подмена понятий.
Цель программирования и написания кода конкретным разработчиком есть. Просто цель проекта при этом неважна.
vsespb
22.05.2019 13:42+1Ну это нужно другим людям. Когда эту фичу будут модифицировать/расширять/поддерживать/писать связанный или похожий функционал, то придёт радостная команда разработчиков и менеджеров, и им нужно будет что-то с этим кодом сделат, сделать быстро, не наделать кучу багов, и чтобы проект не провалился.
Вот для них.
smarthomeblog
22.05.2019 16:01Как я понимаю, работа в аутстаффе/аутсорсе именно для зарабатывания денег.
dustd
23.05.2019 09:39+1Вы не поверите, но ЛЮБАЯ работа — именно для зарабатывания денег. Если нет — это хобби ))
zim32
22.05.2019 11:27Тут на доу недавно HR говорила что плохо доверять бездушному ИИ такую задачу как выбор персонала. Мол не этично. Нуну
xander27
21.05.2019 17:28+28Какой-то у меня противоположный автору опыт. При работе в аутстаф компании, я видел код намного хуже. Хотя и сам и пытался рефакторить. Но руководству то это не особо интересно. Им интересней быстрей продать проект. Потом перешел в продуктовую компанию и отношение к продукту было координально другое. Ты делаешь продукт, который приносит компании деньги. Тебе не просто надо написать код, а от того как этот код будет работать дальше — будет зависеть сколько заработает компания (и ты косвенно). Поддерживать потом либо тебе, либо коллеге из соседнего кабинета — на качество кода и архитектуру уже не забьешь.
Так что мне кажется что автор делает слишком обобщенные выводы на основании своего личного опыта. У меня вот опыт другой, но я не возьмусь утверждать что так у всех.
worldmind
21.05.2019 18:10+4Компании бывают разные и могут находится на разных этапах, стартапы обычно говнокодят ради быстрого видимого результата, а потом если бизнес попёр (и хватает мудрости основателей) приходит время когда для стабильности этого бизнеса надо рефакторить.
goldrobot
23.05.2019 10:26приходит время когда для стабильности этого бизнеса надо рефакторить
И на это забивается болт, ведь для рефактора времени нет, а большому бизнесу нужны новые фичи здесь и сейчас :)worldmind
23.05.2019 10:29Чаще всего да, поэтому в какой-то момент монстр начинает буксовать в говнокоде и приходят молодые делающие более модный продукт и цикл повторяется.
v2kxyz
22.05.2019 13:26+1Мой опыт аналогичен вашему — аутстаф пишет значительно хуже, чем внутренняя команда. В большинстве случаев это происходит по двум причинам — они даже не пытаются вникнуть в бизнес-процесс и у них почти всегда горят сроки, которые тяжело подвинуть ибо бюджет фиксирован. Первая причина конечно утрирована, но часто приходилось видеть технически неверные решения, которые принимались просто из за отсутствия информации/понимания бизнес-процесса.
P.S. Сам сейчас работаю как раз в аутстаффе. И после продуктовой(внутри компании) разработки мне больше всего не хватает довольных пользователей. Это же двойное наслаждение — «о как красиво я решил технически!» и «насколько легче стало жить пользователям».dustd
23.05.2019 09:51+1Писал чуть выше, напишу еще раз: если аутстаф-разработчику приходится вникать в бизнес-процессы компании — компания не выстроила свои бизнес-процессы. В итоге, будет как вы пишете: говнокод и полная неудовлетворенность заказчиком/заказчика. Если компания четко знает что делать внутри, а что можно и нужно отдать на аутсорс/аутстаф/фриланс — все будут довольны. Не аутстафер должен формализовать процессы компании, а компания должна их очень четко описать. Исключения — аудит и оптимизация процессов, либо внедрения каких-либо CRM, когда приходит специально обученный аутстафер, и все это формализует. Разработчиком он, как правило, не является от слова совсем.
v2kxyz
23.05.2019 11:30Вы пишите про «правильного» заказчика, у которого есть желание и ресурсы самостоятельно формализовать процессы и написать ТЗ для разработчиков. Или хотя бы проверить, что делает аутсорсер. Я, к сожалению, работаю у неправильных заказчиков, как внутри, так и в качестве аутстаффера. У них ТЗ, точнее хотелка, которую они гордо зовут ТЗ, обычно умещается на пару страниц А4, где суть укладывается во фразу «автоматизировать процесс XXX».
Из последнего, проводил ревью решения написанного аутсорсерами, выдал вердикт — «ужас, ужас, нельзя такое в прод». Хотя все работает, но при малейшем изменении может сломаться. Заказчик сказал — «ну работает же, а сроки уже прошли, давайте в прод».
Остается надеется, что правильные заказчики существуют, как и правильные аутсорсеры, но я пока их не видел, и до выплаты ипотеки вряд ли увижу :-).
lanseg
21.05.2019 17:37+11Хотя я и не люблю кровавый энтерпрайз, но автор, пытаясь описать динамичность "галер", описал его так, что вышло только хуже.
Такое ощущение, что это они — те самые люди, которые чисто из-за хайпа готовы прикрутить блокчейн, микросерисы, кафку, пюрефку, просто "А вдруг?"balexa
21.05.2019 18:52+16Мда. Так описано, что действительно, лучше бы не говорить. Но в целом да, у меня такое же впечатление от некоторых аутсорсеров сложилось, когда я работал в одном из заказчиков. Что люди путают динамичную разработку и прикрутку блокчейна.
Желаю автору никогда не попасть к хирургу, для которого неважен результат операции, но «вот вчера купил такой клевый скальпель, сегодня им попробую резать. И вообще, давайте экстирпацию пищевода сделаем, это конечно пациенту не нужно, но операция очень интересная, и мне полезный опыт».poxvuibr
22.05.2019 11:07+1Желаю автору никогда не попасть к хирургу, для которого неважен результат операции, но «вот вчера купил такой клевый скальпель, сегодня им попробую резать.
Аналогия не очень. Хорошей аналогией был бы врач, которому важно только чтобы операция прошла идеально, а насколько улучшится от этого жизнь пациента и как он будет рад — это хирурга уже не интересует.
0xd34df00d
23.05.2019 16:22+1А это, кстати, плохой врач? Ведь он же старается сделать операцию идеально.
poxvuibr
23.05.2019 16:34А это, кстати, плохой врач?
С моей точки зрения, это очень хороший врач.
Ведь он же старается сделать операцию идеально.
Вот поэтому и хороший.
mkovalevskyi
23.05.2019 18:19Идеально — это «пациент не умер на столе»? А что там с ним после выписки произошло — нас не волнует? ;)
poxvuibr
24.05.2019 13:07Идеально — это «пациент не умер на столе»?
Вы думаете так хирурги определяют идеальную операцию?
sergarcada
22.05.2019 14:22Желаю автору никогда не попасть к хирургу, для которого неважен результат операции, но «вот вчера купил такой клевый скальпель, сегодня им попробую резать.
И знаете, я бы пошел к этому хирургу, который вместо скальпеля использует лапароскопию — тот самый «новый скальпель».balexa
22.05.2019 14:52-1Прежде чем ложиться под лапароскоп, стоит задуматься, есть ли у вас вообще проблемы со здоровьем.
sergarcada
22.05.2019 15:03+2Если вы пришли на операцию, то наверное не просто так. Но комментатор выше рассуждает по логике «старое — оно же доброе, хорошее, проверенное. Оно же старое, как оно может быть плохим? А все новое — сырое и глючное». А иначе его сравнение не имеет смысла. Не все старое хорошее и не все новое плохое и вообще никакой связи между этим нет. Как и нет смысла пользоваться старым инструментарием, если есть новый (хорошо, более новый) с доказанным преимуществом.
mayorovp
22.05.2019 15:34+1Тут вопрос не в старом-новом, а в подходе к операции. Что важнее хирургу — живой пациент или инструмент попробовать...
balexa
22.05.2019 15:39-1Понимаете в чем дело. Я тут вижу в посте желание пробовать новые технологии и писать код ради кода и технологий. Пользуясь аналогией с хирургом — это когда вы здоровы (насколько это может быть для обычного человека), а он отправляет вас на операцию просто потому что ему интересно с лапароскопом поиграться. Да еще и кидает камушки в огород других коллег — дескать им не операция важна, а здоровье пациента, и бывает, ради того чтобы не навредить пациенту даже скальпель используют по старинке, или вообще консервативное лечение назначают. Вот отсталые дураки.
Может я конечно читаю то что хочу видеть, но мне позиция людей которые «я вот тут делаю что хочу, плевать на вас, но платите мне бабло» глубоко противна.
Ну и собеседование порадовало. Как стало понятно, что в компанию к имитаторам полезной деятельности на галеру может попасть человек, который хочет сделать лучше — его слили.
Ну а серьезно — вот это
машина, которая будет фигачить код днем и ночью, пока аджайловый график фич не придет в нужное состояние. Делать все то же самое в продуктовой фирме я не могу. Мои проектные личности живут очень недолго, и уже через три месяца мозг требует перемен.
скорее всего значит что у автора просто очень низкая квалификация как программиста. Вставлять monkey patches в бешеном темпе и закрывать тикеты костылями он умеет, а вот развивать продукт и поддерживать свои костыли больше трех месяцев скиллов уже нет.v2kxyz
22.05.2019 15:59Не соглашусь с вашим выводом про квалификацию.
Мне кажется, автор просто не успел познать радость создания продукта решающего чьи-то проблемы. А без подобной мотивации реально скучно на одном проекте сидеть больше чем N месяцев. Новые технологии/языки/фреймворки просто позволяют бороться с этой скукой, потому что рождают вызов по их освоению.
Насколько я понял, он успел сделать какой-то инструмент логирования для роботов, но радости ему это не принесло. Вот если бы это самое логирование помогло какую-нибудь реально возникшую проблему решить, то автор может быть и проникся бы.balexa
24.05.2019 11:26Мне кажется, автор просто не успел познать радость создания продукта решающего чьи-то проблемы. А без подобной мотивации реально скучно на одном проекте сидеть больше чем N месяцев. Новые технологии/языки/фреймворки просто позволяют бороться с этой скукой, потому что рождают вызов по их освоению.
Так это то же самое что сказал я, но другими словами.
Вкрутил очередную кафку на блокчейне, даже интересно, а через три месяца это гуано надо поддерживать, и тут становится скучно. Вуаля, на другой проект.
Больше 3 месяцев автор не сидел на одном месте, какие-либо проблемы не решал => у него нет опыта и квалификации, позволяющей решать проблемы и поддерживать свои костыли и продукт больше трех месяцев. Откуда бы этому опыту и квалификации взяться то?
— Вы на пианино играть то-умеете?
— Вы знаете, я никогда не пробовал. Но думаю смогу.
puyol_dev2
21.05.2019 21:37Это все идет от поверхностности. Чтобы разобраться в технологии и понять как правильно и можно ли использовать ее в проекте — нужны значительные временные затраты. А на аутстафе/аутсорсе нет на это времени. Им нужно здесь и сейчас и продать себя подороже, выкрикивая побольше заклинаний «микросервис», «кафка» или так делал амазон, гугл, фейсбук
andreysmind
21.05.2019 22:43+2Ну не только из-за хайпа, еще и для личного самообразования. Готовый полигон, надо только работодателя убедить, что эта технология очень важна для развития продукта и стоит полгода на переписывание с нуля.
HawkeyePierce89
21.05.2019 17:37+35На днях друг хвастался мне, что завернул на собесе чувака, который работал только в аутстафах
Однажды мы с командой проводили тех-интервью, кандидат неплохо шарил, но мы решили, что он нам не подходит только потому, что пришел из продуктовой компании
Адекватность при приёме на работу: уровень «дно донское». Кандидатам очень повезло, что их не наняли и что они не работают бок о бок с такими нанимающими людьми.djinninia
21.05.2019 17:54+11Адекватность, действительно, отсутствует.
Зачем вызывать на собеседование человека, о котором заранее известно, что он не подходит.
навыдумывали много поводов для отказа
Непонятно, зачем выдумывать. Профессиональнее было бы сказать правду.
HellMaster_HaiL
21.05.2019 17:45+6Всегда думал, что уровень «сеньор» — означает, что разработчик не только научился писать «совершенный» код и курить любой фреймворк, но и постиг тонкую грань того, когда и как это делать, чтобы и продукт жил, и глазам было не больно в код смотреть.
И с таким видением, как мне кажется, можно одинаково успешно и комфортно работать над продуктом и в аутстафе.
fillpackart Автор
21.05.2019 18:08-2Синьор, это не тот, кто кодит, это тот, кто разрабатывает
Синьор постиг тонкую грань того, что и когда делать
Синьор не пишет на, синьор пишет с использованием
Синьор не будет тащить новомодный фреймворк
Синьор не будет писать на устаревших технологиях
Синьору всё равно что делать
Сеньору важно, что он делает
Синьор понимает предметную область
Синьор не зацикливается на предметной области
Синьор никогда, никогда не напишет что-то, с чем я не согласен
Синьор то, синьор это
Не надоело вам?Peter03
21.05.2019 18:14+18А как правильно?
Синьор это тот кто получает больше чем джуниор?De-Korg
21.05.2019 19:17+1думаю для бизнеса, это тот, кто приносит больше выгоды в конвертируемом для компании выражении и получает больше чем джуниор
Hardcoin
21.05.2019 19:49+3Размер внутренней ответственности решает. Можешь поддерживать проект так, что б он не рухнул. И свалить не на кого. Джуниор может отмазаться и чинить будет синьор. Синьор может попробовать отмазаться, но чинить всё равно ему (а кому ещё, больше некому).
Формально это не измеримо, поэтому оценивают навыки.
vt4a2h
22.05.2019 13:50Ну, не смотря на сарказм, обычно так и бывает :)
Остальные критерии достаточно субъективны и зависят от многих факторов, например от компании и/или специфики разработки.
bjornd
22.05.2019 17:41Синьор не будет строчить статейки с плохо обоснованным изложением непопулярных мнений ради хайпа.
Luchnik22
21.05.2019 21:48+2Слышал про такой вариант:
Джун — мало ответственности и поэтому за ним нужно следить
Мидл — тот за кем не нужно следить, он сам может за себя постоять
Сеньор — тот кто ответственен за других и себя
Что думаете?
nrgian
21.05.2019 22:11+1Сеньор — тот кто ответственен за других и себя
Это тимлид.
Эта квалификация параллельна джуно-сеньорской.
Paskin
21.05.2019 22:12Мой вариант:
Джун — может накодить
Мидл — может еще и задизайнить
Сеньор — еще и понимает все аспекты решаемой проблемы
youlose
21.05.2019 23:18+3Джун — тот кто решает простые проблемы сложным путем.
Мидл — тот кто решает простые проблемы простым путем, сложные сложным.
Сеньер — тот кто решает сложные проблемы простым путем
niksamokhvalov
22.05.2019 09:08На самом деле так:
— Джуниор думает, что всё знает.
— Мидл знает, что ничего не знает.
— Сеньор знает, что ничего не знает, но ему уже всё равно.
WhisperingOak
22.05.2019 09:33Зачем отступать от классики?
Джун должен знать всё.
Мидл должен знать в какой книге находится всё, что знает джун.
Сеньор должен знать где находится мидл.
shybovycha
22.05.2019 09:24у каждой компании… да что там — у каждого начальника / менеджера свое видение сениора, мида и джуна. много я уж этих матриц соответствия и списков критериев насмотрелся
djinninia
21.05.2019 17:46+10Имеет смысл в описании вакансии указывать: разработчикам из аутстафа (или продуктовой компании) просьба не беспокоиться.
Или же на этапе скрининг интервью не пропускать дальше неугодных.
Так можно сохранить своё и чужое время.
Peter03
21.05.2019 17:58+3Аутстаф аутстафу рознь. Знаю человека который 17 (семнадцать) лет работает на том же месте как аутстафер.
Сам лет 10 работал в аутстафе и столько же на продуктовых проектах.
Аутстаферы в большинстве скрытые говнокодеры.Пухов ежедневно осматривал пароходные машины и писал рапорты об их болезни:
Ввиду сломатия штока и дезорганизованности арматуры, ведущую машину парохода „Нежность“ пустить невозможно, и думать даже нечего.
Пароход же по названию „Всемирный Совет“ болен взрывом котла и общим отсутствием топки, которая куда делась – нельзя теперь дознаться.
Пароходы „Шаня“ и „Красный Всадник“ пустить в ход можно сразу, если сменить им размозженные цилиндры и сирены приделать, а цилиндры расточить теперь немыслимое дело, так как чугуна готового земля не рождает, а к руде никто от революции руками не касается.
Что же до расточки цилиндров, то трудовые армии точить ничего не могут, потому что они скрытые хлебопашцы.De-Korg
21.05.2019 19:13+1середину найти трудно, но есть пара но…
1) есть риск 5+ лет просидеть на одном проекте в аутсорсе и на древнем стеке, иначе, если постоянно менять аутсорс проекты (а для этого и компании кстати) есть риск стать эникейщиком, так и не научившись делать что-то стоящее от и до
2) почему страдает качество, посыл не мой:
Аутсорсер живёт за счёт разницы между зарплатой и ценой продажи человековремени — поэтому игра, с некоторыми упрощениями, имеет нулевую сумму, а зарплата — конкретный потолок. В продуктовике экономика другая — потери из-за высокой текучки (или даже необязательно высокой — если уходят сотрудники высокого уровня компетенции) существенны настолько, что «как можно меньше» может быть намного выше рынка.
Peter03
21.05.2019 19:59Идея для следующей статьи — Филипп (он как раз в правильной возрастной категории или кто-либо ещё, у кого есть время и желание) устраивается (пытается) на испытательный срок джуниором в компанию, работает пару недель и описывает приключения. Заодно корректирует самооценку.
mapron
22.05.2019 18:43корректирует самооценку
Ну совсем-то не загибайте, Хабр это технический, а не фантастический ресурс)
nrgian
21.05.2019 21:04Я тогда не придал этому значения, а сейчас понял — похоже, разработчики, которых по три раза за год продают на чужие проекты, и разработчики, которые пять лет фигачат один продукт — совсем разные профессионалы. Обстоятельно покопавшись в себе, я понял, что не просто отношу себя к первым, но и подсознательно презираю людей, которые больше двух лет работают над одним проектом.
Возможно, этому виной плохие примеры. Одна продуктовая фирма, где я работал, использовала C# 2.0. ДВА НОЛЬ. Аргументировали они просто: проект большой, если переносить его на новую версию, наплодим кучу багов. И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.
А вот тут непонятно.
Если «по три раза в год попадать на на очередные продукты», то эти продукты — новые, все как один?
В том время как аутстафная разработка — это всего лишь разработка продуктов корпораций силами внешних специалистов.
Откуда там по 3 раза в год новые технологии?
Ведь это такие же «долгоиграющие проекты».
Исключения в виде «коротких» проектов бывают. Но они бывают и в продуктовых и в аутстафных же.
funca
21.05.2019 23:55+1Приходит тело на проект. Плюется, что за говнокод. Начинает переписывать на новый чудо фреймворк. Переписав процентов 5 несчастного легаси, понятно, что самой понятной его части, через пару месяцев, ибо нервы не выдерживают, уходит на другой проект. На его место берут новое тело. Которое плюется, что за говнокод… За год у всех в резюме появляется опыт работы с чудо фреймворком и по нескольку проектов за плечами.
harvys
22.05.2019 11:03Так же наблюдаю подобное!
Выход: работает — не трогай, для нового — пиши новый код, если надо изменить старое сначала дублируй в новое место и применяй tick-tock принцип для уменьшения долга.
Главное этот процесс на рельсы поставить и всем объяснить, новичкам — дважды.
Ситуация в статье просто описывает очевидное — мы все разные, а подбор кадров дело тонкое, кого наберешь — так и поплывешь. В разные моменты проекта нужны разные роли от сотрудников — это тоже надо понимать, поэтому лояльность сотрудников очень важна, а это в резюме увидеть можно.vav180480
22.05.2019 13:13Я работал в компании у которой были и свои проекты и сайты на поддержке, я как продуктовик вроде работал нормально, но время от времени были задачи с поддержки, жаловались что работаю долго, на последней задаче дали оценку 3 часа. Суть в том что было два магазина на поддержке сделанные на одном движке, один программист навесил костыль на всех магазинах (взял кусок похожего кода из одного места и повесил в другом), остались нерешенные косяки, второй программист навесил костыль на одном из магазинов порешав часть проблем, но остались еще нерешенные косяки, но про это никто не в курсе был, мне на другом магазине сказали что нужно сделать такой же второй костыль, я начал делать и тестить и нашел проблемы во втором костыле, вместо того чтобы вешать третий костыль поверх второго костыля на первый и второй магазин я распотрошил код и разобрался в изначальной проблеме которая решалась первым костылем и вместо нагромождения костылей сделал элементарную правку буквально в пару строчек, но на все про все ушло 3 дня — уволили.
nrgian
22.05.2019 21:02и разобрался в изначальной проблеме которая решалась первым костылем и вместо нагромождения костылей сделал элементарную правку буквально в пару строчек, но на все про все ушло 3 дня — уволили.
Не верю.
Ну премию могли бы не дать — это верю.
Сейчас дефицит квалифицированных — просто так не разбрасываются теми, кто действительно может решить проблему.
Что-то вы не договаривайте.dzsysop
22.05.2019 22:52Некомпетентность это штука вечная. Мы не можем знать что за контора и что за специалисты там были. Если контора привыкла к костылям — они вполне могли и не понять «души прекрасные порывы».
Решить проблему и «решить» проблему — две большие разницы, но для пользователя и зачастую для заказчика разницы никакой. Для не технического манагера тоже разницы никакой. Для неквалифицированного тимлида или синьора — тоже никакой. Разница заметна только тем кто понимает, а таких точно меньше чем 100%. Поэтому вполне допускаю что человека могли уволить.
Просто если товарищ реально рубит, то расстраиваться точно не стоит. Найдет правильное место с правильными людьми и правильными проектами и будет ему счастье. А это просто эпизод на который и внимания то обращать особо не стоит.
vav180480
23.05.2019 11:091) Я не сказал что был на испытательном сроке, это был 2 или 3 месяц моей работы там, посему «расстались легко».
2) Это была «последняя капля» потому что мой подход в остальных задачах был точно таким же и проблемы в остальных задачах были точно такие же:)
3) Дефицит не дефицит — я оправдываться не стал, кесарю — кесарево, слесарю — слесарево, компания на самом деле была не плохая, просто не сошлись характерами.
juray
22.05.2019 14:43применяй tick-tock принцип
Вот вы так пишете, будто это уже широко известный термин в методологиях разработки софта.
Я погуглил — весь инет завален описанием стратегии выпуска микропроцессоров (тик — микроархитектура, так — техпроцесс), каковое значение я в первую очередь и вспомнил, но не смог сообразить, как это можно распространить на рассматриваемую область.
И только отдельными вкраплениями в поисковой выдаче все же нашлись статьи про чередование «изменение функциональности — наведение порядка». Например, "The Tick-Tock Innovation Model Applied to Agile Methodology". (Привожу ссылку для тех читателей комментов, кто как и я, первый раз встречает этот термин применительно к разработке софта).
Вообще, хороший принцип, и довольно универсальный и очевидный — «есть пауза — наведи порядок». Вопрос только в наличии этих пауз. Если приходится постоянно гнать функциональность, становится не до ликвидации долга. Как говорится, «некогда пилу точить — пилить надо!» Конечно, надо бы всё же выискивать такую возможность, буквально выгрызать… но не всегда получается.
Вон и ниже в комментах пишут:за все время ни в одной компании не было статьи расходов на рефакторинг и годную модернизацию кода
KirEv
21.05.2019 21:18начиналось, наверное, как у большинства: фриланс, чем не аутстаф (только сам себе менеджер, директор, етс.), далее случилось счастье — в течении многих лет основная работа в продуктовой компании, за все время, по дороге, и с продуктовыми разными работал, и аутстаф, да все не по душе последнее.
Если в продуктовой у тебя заслуженный авторитет (а не из раздутого резюме): волю дают принимать важные архитектурные решения, плотно участвовать и корректировать технологический вектор развития продукта и не лепить блокчейны, кафки, амазоны там где это неумесно, экономя расходы аппаратные и человеко\часы.
Но за все время ни в одной компании не было статьи расходов на рефакторинг и годную модернизацию кода.
В прошлом году одна из аутстаф-компании на меня обиделась и нежно выгнала, або тот проект который хотели взять планировал чудовищный стек технологий на диких условиях, когда заказчик требует отчет утром (план), вечером — результат (и не сколько годных коммитов), + активный чат со ВСЕМИ членами команды (человек шесть)… Менеджеры очень хотели этот проект из-за огромного бюджета. На том и разошлись…
Кроме того, в продуктовой компании, которая на рынок вышла не вчера, есть масса вещей для работы, далеко за пределами той части, над которой трудился с самого начала, я уже не говорю про новые фичи.
ЗЫ: не люблю эти ваши собеседования… там 90% треш… знакомый проходил недавно на позицию middle nodeJs — не прошел, не знал чего-то там по html5. )nrgian
21.05.2019 21:57Менеджеры очень хотели этот проект из-за огромного бюджета. На том и разошлись…
А вы не хотели этот проект ради денег?KirEv
21.05.2019 23:24нет, овнеры\коовнеры изначально смотрели на проект как на дойную корову, и если сначала пытался донести каким образом можно добиться результат, после слов моего руководства: «просто будешь делать какие-нибудь комиты и активность в чате..» и «игнорируй его, ничего не отвечай» (спустя обещанных 2 часа со стороны моего руководства заказчику) — достаточно было аргументов твердо решить не участвовать.
кроме того, от геморности проекта ставка не меняется, более того, в этой компании овер-тайм не учитывается, а вдруг часов не хватает — минусуют с зп (по часах ставку определяют), и чем меньше рабочих дней в месяце — тем выше стоимость профуканного часа… и другие странные вещи…
аутстаф )
у каждого свой опыт.
jewalky
21.05.2019 21:32+5Хочется замолвить слово за людей, которые вникают в суть проекта. За тех, кому интересно что нужно сделать и главное для чего (а соответственно как быстро и насколько вдумчиво), а не только как это сделать технически.
Осторожно, много букв.
Я работаю в стартапе на удалёнке, уровней абстракции между мной и заказчиком — ноль. То есть он мне пишет в скайп что он хочет видеть, мы где-то полчасика беседуем если я чего-то не понял, после чего он уходит на какие-то свои митинги. К концу дня он возвращается и обычно видит всё, что хотел.
Бывают конечно ещё сложносоставные задачи, которые разбиваются на «спринт» по тематике — то есть создаём эпик, начинаем делать первую задачу в понедельник, в пятницу всё работает и деплоится на прод (иногда деплоится в следующий понедельник). Спринт в кавычках, т.к. методологиями по понятной причине никто не заморачивается.
Поначалу меня очень смущало, когда он внезапно с описания задачи переходил на описание своего бизнеса и пересказывания митингов. Но потом я понял, что в общем-то это позволяет мне одному выполнять задачи не менее эффективно, чем это делала команда из пяти человек до меня (полусуществующий БА, два фронтенда, два бекенда). При том что этих пять человек заказчику приходилось микроменеджить лично (вплоть до описания полей в БД для бекенда — как написано, так и сделают, даже если это было набросано за пару секунд и является примером, а так откровенным бредом). Потому их и уволили, собственно, а я плавно перешёл из QA-автоматизации в разработку — сначала вынужденно (пока искал работу), а потом з/п подняли и таки остался.
Самое главное, что эти разработчики не были куплены у галеры, они просто привыкли работать на большом продукте, где между ними и непосредственно заказчиком находится пара слоёв менеджеров, аналитиков, дизайнеров и прочих, которые разжуют всё.
В заключение хочется сказать, что существует два совершенно разных типа людей. Оба называют себя программистами, но при этом одни могут и хотят видеть картину в целом, а для других «за мкадом жизни нет» (то есть за их областью ответственности).
Они нужны в совершенно разных ситуациях, но при этом у первых есть преимущество: любой может целенаправленно абстрагироваться от целей проекта и прогать по джире, но очень сложно научить «марширующего» программиста мыслить более высокоуровнево.
А про отношение вида «состояние проекта в джире важнее, чем в реальности»…
Ну тут вообще уже нечего сказать. Воспитывавшие меня люди такое называли «подстава». Чисто по-человечески так делать нехорошо, если конечно заказчик со своей стороны поводов не давал.
P.S. По работе программирую на трёх языках стабильно и ещё около четырёх знаю по верхам на уровне «увязать вместе чтобы работало» и «понять шо ж там сломалось и почему». Также имею опыт работы с библиотеками, по которым документации нет и не будет, зато есть высокоуровневый диздок или вообще научная публикация в PDF с кучей матана внутри. Но собеседование на разработку скорее всего не пройду, потому что людям нужно, чтобы я на бумажке по памяти прогал с использованием новейших фреймворков :)
И именно такие требования на собеседованиях и появляются из-за засилья аутстафферов, умеющих проходить собесы и концентрирующихся на знании фреймворков, а не на поставленной задаче.
dom3d
21.05.2019 22:49+2Мы с автором из разных вселенных.
Я люблю программирование потому, что программы облегчают труд людей.
И радуюсь, когда у меня получается новая классная фича.
ivlevAstef
22.05.2019 05:52Так сложилось что мой опыт где-то 50/50. Причём побывал в нескольких аутсорс и нескольких продуктовых компаниях.
И там и там я видел плохой код, и там и там были проблемы с менеджементом и мамонты технологические и т.п.
Но деление между аутсорс и продукт есть — но оно заключается в личных предпочтениях. Кому-то Интересно постоянно что-то новое, новые подходы/языки/проекты и они хотят драйва. А кому-то интересно укреплять базу, развиваться в глубь. Это как кататься на мотоцикле, прыгать с Тарзанки/парашюта и т.д. Против хождения в одно и тоже места условно каждый день (например смотреть закат).
Но поверьте — специалисты хорошие есть везде, и просиживатели штанов тоже.
Я себя отношу больше к продуктовикам — мне база важнее чем технологии умирающие быстрее чем проект. но это не значит что я буду сидеть на старом языке или не использовать хороший Фреймворк (и точно не значит, что я не в курсе новинок). Просто перед использованием нужно задать вопрос — а что мне это даст? И только если плюсы перевешивают минусы, только тогда использовать.
Но по факту, при смене работы и при приеме на работу я ни когда не смотрю на продукт/аутсорс — все зависит от компании/директора/коллектива.
Если в продуктовую команду на собес приходит человек и с горящими глазами рассказывает как он за год пользовался 50 технологиями, то обязательно задам вопрос — «а ты уверен, что хочешь к нам? У нас не будет кучи технологий, зато будут сложные архитектурные задачи.», а человек в праве сам решать интересно ему это или нет.
Если в аутсорс компанию приходит человек, но ничего не слышал о современных подходах, то также возникает вопрос — «а ты готов постоянно развиваться вширь?», и также человек должен решать сам.
А грамотный лид всегда будет держать хотябы одного разработчика развитого в ширь и хотябы одного в глубь.
Снова много букв…
lamerok
22.05.2019 08:45По своему опыту могу сказать, что да в продуктовых компаниях из года в год делаешь один и тот же код из продукта в продукт, переиспользуешь уже готовые и проверенные решения, хоть и основанные на "старых" технологиях. И это не потому что разработчики не хотят использовать новое, а потому что код, проверен временем, отлинтован, юнит тестирован, проверифицирован, и проревьин. Он надежен, и смысл тратить ресурсы и время на тоже самое, но по современному, нет. Это потенциально занесет ошибки.
Мой опыт говорит, что код продуктовых компаний намного чище и надежнее.
sd1ver
22.05.2019 10:24выныривает из аврала и суеты
Черт, а что уже пятница? Не успел все комменты прочитать — так какие же фломастеры красивее других?
DarthVictor
22.05.2019 11:31Он рассказывал не как продукт сделан, а что продукт делает для людей. У нас спрашивал, что мы делаем, а не как и с помощью чего. Мы, конечно не говорили друг другу: «Ему важен продукт, а должно быть насрать», но были единодушны в своем нежелании работать с ним, и навыдумывали много поводов для отказа.
Зато результатами его труда люди пользуются добровольно.
Да и по теме статьи. Непонятно, почему на на аутстафе людям должно быть не насрать на качество кода. Наоборот время нахождения человека на проекте в аутстафе должно быть меньше. Поддерживать их говнокод другим.
Что показательно код, который я видел после аутстаферов действительно был на новом стеке React+Redux+TS. И по нему было видно, что великий комбинатор писал под браузер второй раз в жизни.
Из увиденного как унаследованного так и попавшего на ревью от аутстаферов, которых прислали нам помочь
- три await подряд, ни один из них результаты предыдущих не использовал
- человек мутирует в течение простыни реактовский стейт, затем делает this.setState({...this.state}
- тип данных приходящий от сервера отличается от типа внутреннего представления клиента несколькими полями, при обращении к ним объект приводился к any
Зато будьте уверены у всех в резюме будет React+Redux+TSdustd
23.05.2019 10:29Тут, к сожалению, вопрос к компетентности разработчика в целом. Если человек не умеет, его нужно либо учить, либо менять. С аутстафером даже проще в этом плане — не компетентен, до свидания, пришлите другого. Нет всяких ТК РФ и прочего, это не ваш сотрудник. В остальном — ревью кода проводится одинаковое что для «своих» продуктовиков, что для «чужих» аутстаферов, говнокод заворачивается в любом случае.
Koshak118
22.05.2019 12:01-3Автор делает два основополагающих предположения на которых строит все остальное: что аутсорсерам кто-то дает право выбора технологий и методологий и что в продуктовых компаниях работают на древнем стеке.
Очевидно что эти предположения не только не аксиомы, но и верны только для очень частных случаев, и делать из этого глобальные выводы о природе различий между разными типами разработчиков так себе занятие.
Но в любом случае тема интересная. Как по мне — разработчик, который не понимает и не хочет понимать, что его код делает для бизнеса — это не разработчик, а кодер. Машина для создания кода для другой машины. Очень ограниченное и не очень полезное создание, которое по определению не может писать «хороший» код, где под «хорошим» кодом я понимаю не код, использующий последние фреймворки и фичи из последнего релиза языка X, а код, который полностью отвечает требованиям продукта, который легок в подержке, интеграции и масштабировании. Все это абсолютно невозможно получить от человека которому «насрать на продукт». Вот именно такие «насрать на продукт» кодеры есть говнокодеры, и таких есть везде — и в продуктовых компаниях, и в аутсорсе.
Вообще мне лично гораздо больше нравится определение «Software Engineer», чем «разработчик». Хорошие программисты — инженеры. А инженер просто не может работать, когда ему «насрать на продукт», иначе это не инженер, а так, чернорабочий на подхвате.Whuthering
22.05.2019 12:04«Самое главное отличие кодера от программиста — это что кодер знает, чем кодер отличается от программиста, а программист знает, что никакой разницы нет.» ©
vvpetrov91
22.05.2019 13:14Да все верно подмечено. Как тестировщик, работающий с разными проектами и разными разработчиками уже не первый год, могу сказать что так и есть. Если прогеру пофиг на продукт, то он ВСЕГДА получается говном. А вот кому это заявление кажется странным, тот скорее всего и делает говно.
dustd
23.05.2019 10:37Как заказчик-продуктовик, работающий с аутстафом последние эдак лет 10, могу со всей ответственностью сказать: говнокод вы получаете не в том случае если прогеру пофиг на продукт, а в том, если вы не дали ему требования, которые необходимо выполнять, чтобы не получилось говнокода. И абсолютно индифферентно, продуктовик или аутстафер этот код будут писать.
Koshak118
23.05.2019 12:49"… если вы не дали ему требования, которые необходимо выполнять.." — вот, давайте поговорим об этом. Если у меня есть разработчик, которому надо до мельчайших деталей определять что и как делать, постоянно его контролировать, постоянно самому следить, что неделей назад определенные требования фичера не нужно подкорректитовать после последнего митинга по интеграции, самому проверять что человек не тащит нерелевантные, но кульные фреймворки в репозитарий — это плохой разработчик. Потому что такой микроменеджент простителен (необходим) только зеленому джуниору только что из университета.
Я утверждаю, что разработчик, которому «насрать на продукт», неважно, продуктовик он или аусорсер (хотя среди аутсорсеров таких намного больше), является именно таким плохим разаботчиком. Он будет делать ровно то, что ему сказали, ни на миллиметр меньше, но и не больше ( а если и больше — то не ради продукта, а ради чисто своей выгоды/любопытства). Если вдруг какая-то характеристика фичера вступает в противоречие с другим, бОльшим фичером или просто «опасна» в контексте всего продукта — он этого не увидит и не эскалирует мне. Если его фичер жрет память и CPU в кривых вложенных циклах — ему будет наплевать, потому что никто не определил ему, сколько памяти ему можно брать. Он никогда не придет ко мне и не скажет — а давай вот здесь сделаем вот так, потому что я пил кофе с чуваком из фронтенда, и оказалось, что наши API не учитывают это и это — ему за это не плОтят, ему насрать на продукт. Можно продолжать дальше, но я думаю что мысль ясна.
И вот когда такие разработчики называют себя королями разработки потому что они используют новейшие фреймворки — мне сначала с них смешно, потом грустно, потом они идут искать другое место работы.dustd
23.05.2019 14:10Требования — это то, как надо писать код, чтобы его можно было легко читать, поддерживать, рефакторить, переиспользовать. В основном — это выжимка из PSR`ов и "лучших принципов", типа DRY, KISS, SOLID и тд, а также указания где их использовать нельзя в принципе (да, и так бывает). Плюс, мой собственный бред, на тему как надо (будем считать так). Если что — про кривые вложенные циклы там даже написано )))) Всего, в моем случае, это 3 документа на 142 страницы А4 в сумме. Последний раз изменения в эти документы вносились вчера, до этого 2 месяца правок небыло. Выполнение этих требований обязательно для прохождения Code Review. Не выполнение — достаточный, но не необходимый (есть еще ТЗ) аргумент для деклайна PR. ТЗ — требования необходимые для автоматизации конкретного бизнес-процесса, либо требования к ИС в целом. Невыполнение ТЗ — также деклайн. Если разработчик выполнил и требования и ТЗ — его код будет принят и оплачен, вне зависимости от его отношения к продукту.
Koshak118
23.05.2019 17:46+1Мы, собственно, говорим про одно и тоже, но оцениваем его по разному. Вы говорите что вас устраивает интерфейс ТЗ — бери и выполняй. Сделал — молодец, не сделал — п… ц. Я говорю, что разработчик, воспитанный на четком выполнении кем-то написанного ТЗ — это что-то вроде исполнительного солдата, чернорабочего, которому нельзя доверить что-то большое и ответственное, таск, который может содержать подводные камни и неожиданные ситуации.
Я согласен, что с аутсорсерами по другому нельзя, и именно поэтому среди них так много деревянных солдат Урфина Джюса. Лично мне с такими работать неинтересно, и более того, нанимать таких себе в компанию — стрелять себе в ногу. Мне не нужны исполнительные солдаты, мне нужны умные, инициативные и не боящиеся ошибок инженеры, которых прет от того, что они делают.
irod87
22.05.2019 13:41Сдается мне, автор и сам понимает что его отношение к работе (когда упор на написание кода, а не на продукт) неправильное, поэтому и озвучивает его с таким вызовом, типа «да, я такой, и не хочу меняться». Было время, у меня было такое же отношение. И я рад что я смог его изменить (пока еще не до конца, правда). Меня тоже не волновал конечный продукт, я тоже видел только код, я горел «правильным кодом». И в результате перегорел и полностью разочаровался в кодинге. Пришел к тому что кодинг не стОит того чтобы ставить его на пьедестал в своей жизни. Все эти языки и фреймворки стали казаться мне довольно ограниченными и просто скучными. Ум стал требовать новых челленджей, и написание кода его уже не могло удовлетворить. Все эти паттерны, командная разработка, аджайл — да не такое уж это и умное занятие на самом деле, на челлендж не тянет. А теперь я стараюсь думать в первую очередь про готовый продукт, что он даст юзерам. А код — просто средство, инструмент. И при таком подходе ко мне опять вернулось удовольствие от кодинга. Ведь я больше не отношусь к нему серьезно.
nikaforward
22.05.2019 14:32+1После работы в аутсорсе, заработал субъективное отторжение к нему на всю жизнь (даже был близок к тому, чтобы получить отторжение ко всему программированию). После долгого размышления пришёл к выводу: самое ужасное для меня в аутсорсе это то, что моя работа не имеет значения.
Поясню: в аутсорс-компании центром прибыли являются менеджеры (PM, аккаунты, по продажам и т.д.), именно они приносят компании деньги. А технические специалисты являются центром издержек. Да, без них никак нельзя, ведь надо кого-то продавать заказчикам. Но, в целом, они находятся на вторых ролях. В итоге все решения принимаются менеджерами среднего и младшего звена. Зачастую даже технические, зачастую вопреки опытным разработчикам в статусе лидов.
Несколько примеров из моей практики:
— Тесты. TDD не было никогда. Как бы разработчики не настаивали. В половине проектов удавалось продавить интеграционные тесты, но при первом же цейтноте менеджеры их отменяли. Пишешь код, который нельзя показать заказчику — валяешь дурака.
— Работа с системой контроля версий. Почему мы не можем показать фичу заказчику, когда её код уже написан? Что значит не можете смержить, потому что ждёте какой-то там кодревью? На лицо явный саботаж. Делайте merge немедленно!
— Самый показательный случай: менеджер попросил срочно поменять реализацию, поскольку в последний день спринта выяснилось, что у заказчика другое видение. Я предложил по быстрому заговнокодить (да, знаю, сам виноват), но с условием, что нужно будет выделить время, чтобы сделать нормально в следующем спринте. Конечно, в следующем спринте мне отказали с аргументом: «На тестовом всё и так работает, а что будет на проде нам совершенно неважно, потому что они будут выливать на прод уже после того, как мы закончим с ними сотрудничество.»
На всё это можно возразить: чувак, а какая тебе разница? Ты работаешь, получаешь за это деньги. Расслабься и получай удовольствие. Но даже если для кого-то это и недостаточно неприятный опыт, то есть пару следствий из такого положения дел.
Во-первых, профессионализм ничего не значит. Более того, он вреден. Лучше писать быстро, а не долго. В итоге имеем, что профессионал, с желанием написать действительно работающий и способный к расширению (для добавления новых фич) код, будет критиковаться. А быстро шлепающий говнокодер нахваливаться. Естественно, расти как профессионал в таких условиях как минимум трудно.
Во-вторых, место профессионализма займёт другое качество. В моём случае это была лояльность. Хорошим был сотрудник, который готов работать на выходных и всем доволен. А тот, который на ретроспективах говорит о проблемах был плохим. Потому что «мы команда, а в команде важно мыслить позитивно.»
P. S. Конечно это мой сугубо личный опыт. Возможно, что есть аутсорс компании, в которых этого нет. Возможно, в продуктовых это тоже присутствует. Но, как мне кажется, продуктовые компании больше смотрят на качество сервиса, которые они предоставляют. Потому что от этого напрямую зависит их прибыль. А, следовательно, приходит понимание ценности экспертизы технических работников.lightmaann
22.05.2019 15:24+1Мысли хорошие, но никак не могу согласиться с последними двумя абзацами.
Профессионализм не может ничего не значить, так как в процессе принятия решений он является ключевым фактором. Если при обсуждении проекта условный разработчик не может описать менеджеру проблемы, которые могут возникнуть, предложить определенные решения и рассказать о плюсах и минусах данных решений, зачем вообще нужен такой разработчик?
И обратное верно — чем лучше развиты экспертные навыки, тем лучше менеджер сможет донести эти моменты до заказчика, а компания, соответственно, получить больше выгоды.
Так что профессионализм в «аутсорсовой» разработке очень даже много значит, не говоря уже о зарплате, уровне ответственности и т.д.
Если же разработчики пишут плохой, неподдерживаемый код, то проекты будут ломаться, заказчики будут уходить, а компания терять деньги. Ни один владелец бизнеса не хочет терять деньги.
По поводу «лучше писать быстро, чем долго» — мне кажется вне зависимости от типа компании, надо быть просто работать эффективно, и не в контексте «эффективных менеджеров», а просто грамотно распределять время на задачи. ИМХО, но я повидал много людей, которые растягивают какие-то простые задачи на недели, а сложные пытаются решить за пару дней, нарушая при этом всевозможные сроки с дедлайнами. Опять же, профессионализм и здесь играет роль.
А если компании действительно абсолютно параллельно на то, как работает человек, я бы задумался над тем, чтобы сменить место работы, ведь никто никого не заставляет)nikaforward
22.05.2019 16:51Под профессионализмом я имел в виду навыки написания систем, которые а) способны работать в боевых условиях, б) созданы с учетом добавлений/изменений. Да, каждый может подразумевать под этим словом разные вещи, тем более бизнес.
Как раз дело в том, что бизнес возлагает принятие решений исключительно на менеджмент. Разработчики в принятии решений не участвуют вовсе. Вплоть до технических, про которые я и упоминал. Канал «разработчик» <-> «бизнес» не налажен, объяснить ему про потерю денег не получится (не говоря о том, что бизнес не считает, что разработчик в этом разбирается). Возможность потерять клиента в мифическом будущем не интересует бизнес, потому что через год это через год. А если мы сейчас скажем клиенту, что нам надо, к примеру, не месяц, а два, зато будет качественно, то клиент уйдёт к тому, кто готов сделать за месяц. И мы потеряем клиента прямо сейчас. Что там говорить, если менеджера зачастую не интересует, что будет на следующей неделе, главное выбить показатели текущей.
В итоге менеджмент принимает решения для того, чтобы выдать показатели здесь и сейчас. Мнением технического специалиста не интересуется никто. Следовательно, у технического специалиста нет ответственности. Нет ответственности — его деятельность не имеет значения. В итоге пишешь не предназначенный для прода код по техническим решениям человека без технического бэкграунда.
Да, по поводу ухода из такой компании я абсолютно согласен (да и вообще по поводу любого ухода). Я даже не хочу сказать, что такая бизнес-модель плохая, так делать нельзя и фу-фу-фу. Если бизнес зарабатывает деньги таким образом и процветает, то флаг им в руки. Опять же, возможно это мой личный негативный опыт. Но я не вижу причин, по которым в аутсорс-компании бизнес бы заботился о том: как код написан, насколько там современная версия, сколько мы времени сэкономим в будущем, если сейчас потратим больше времени на изучение чего-то нового и т.д. Чтобы бизнес задавал вопросы разработчику по его экспертизе. Главное это получить деньги с заказчика здесь и сейчас. С этим справляются менеджмент, а разработчики с желанием высказать своё мнение о том, что неплохо было бы написать то, что будет работать и через год; или желанием потратить больше времени сейчас, чтобы сэкономить через пару месяцев, идут лесом. И я вижу предпосылки к тому, что об этом как раз будут заботиться в продуктовых компаниях. И у разработчика будет больше ответственности. И больше смысла ходить в офис.
Whuthering
22.05.2019 17:08+1Что интересно, у меня в жизни было все в точности до наоборот.
Начинал карьеру и много лет проработал в продуктовой фирме. Продукт вполне серьезный и для весьма ответственных применений, продается под своим именем, но дорабатывается с пожеланиями больших покупателей (добработки становятся частью продукта). И вот там было все как вы описали в начале: полное отсутствие тестов, наплевательское отношение к системе контроля версий (пушим в мастер!), «херак и в продакшн» потому что сроки релиза горят без последующего рефакторинга (потому что там уже следущие задачи и строки), костыли (проект старый, архитектура имеет ограничения, а переписывать основательно нет времени — фичи релизить надо, сроки горят) и т.д.
А после этого переехав в другой город попал в большой международный аутсорс, сначала на одного заказчика, потом на другого, и там мне очень понятно показали, как делать надо и не надо, и приучили к правильным практикам и хорошему вкусу.v2kxyz
22.05.2019 17:31Есть подозрение, что ваш продукт покупали не потому что, он хороший, а потому что его умели продавать большим заказчикам, вероятно окологосударственным. Либо он был новый и быстрорастущий на своем рынке. Я уверен, что рано или поздно его придется переписать.
Вот, не так давно была история про переписывания — habr.com/ru/post/441456.Whuthering
22.05.2019 17:38Заказчики большие, но государственных из них была примерно только треть. Продукт наверное нельзя было назвать прям «хорошим», но он дело свое делал, а да и у конкурентов всё было ощутимо хуже :)
Ну, а про то что его рано или поздно перепишут (может быть уже переписывают, давно никого оттуда не видел) — это само собой.
bjornd
22.05.2019 16:37И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.
Врач такой приходит на работу и говорит: Я конечно понимаю что вы, уважаемый пациент, хотите жить. Но тут есть новая методика, которую очень хочется опробовать. Вероятность смерти — на 80% выше, но зато если выживите — будете бегать на 10% быстрее и лечить мне вас потом будет проще и интереснее. А теперь считайте от 10 до 0…v2kxyz
22.05.2019 17:22До откуда вы такие аналогии берете? С чего вдруг вероятность смерти 80%? Новые препараты более-менее регулярно появляются и их, так же как и ПО, тестируют перед тем как в реальный мир пускать. И я уверен, что в процессе тестирования множество препаратов показывают неудовлетворительные результаты и в проде их не используют. Чем это отличается от переписывание софта на новый лад? И внезапно, если этого не делать, то возможно пациент(бизнес) умрет(Нокия например), особенно если он изначально построен на IT составляющей, потому что придут конкуренты с новой технологией, которая «быстрее/выше/сильнее».
vav180480
23.05.2019 09:57Наверное оттуда что если в названии стартапа есть слово «блокчейн» (машинное обучение, нейросеть далее по списку) то он будет стоить дороже даже если основному функционалу это не нужно и блокчейн (обучение нейросеть далее по списку) прикручен для галочки в неосновной функции и даже там без него можно было обойтись. А теперь представим что на работающий проект пытаются прикрутить переписанный функционал на хорошо оттестированной технологии, проблема будет не в хорошо оттестированной технологии а в том как перепишут на конкретном проекте
cross_join
22.05.2019 18:29Вопрос власти, на самом деле. Если у технарей и ответственных за качество есть контроль, то долг управляем, будет и рефакторинг, и тесты, и развертывание с интеграцией. Если же все в руках продукт-менеджеров или, что еще хуже, продавцов, то пиши пропало, корову будут доить досуха.
vav180480
23.05.2019 10:08-1Тебе дали задачку прикрутить кнопочку на сайт который ты до этого не видел и скорее всего больше никогда не увидишь (это ключевой момент), ты можешь прикрутить кнопочку быстро, а можешь правильно, но платят тебе за быстро, а не за правильно (попробуй обосновать заказчику увеличение временных затрат вдвое-втрое, скорее всего он решит что его хотят на… обмануть) Еще веселее ситуация когда ты прикручиваешь для своей плевой кнопочки библиотечку на пару мегабайт которая интересна лично тебе, ты ее пихал в кучу других проектов, которая завязана на текущую версию jQuery и использует deprecated функции (шо это?), после того как через пару лет на сайте уже другой такой же бедалага перейдет на новую версию jQuery и естественно не проведет регрессиооного тестирования твоей кнопочки (а ему это зачем? и что такое это ваше регрессионное тестирование?), то владельца сайта ждет супрайз:)
dustd
23.05.2019 11:37+1Хочу посмотреть на проблему с другой стороны "экрана". То есть со стороны человека, который заказывает музыку.
Для начала, давайте определимся с терминологией. Аутстаф — сотрудник, работающий в другой компании, но предоставленный мне для реализации моих задач. Проходит техническое собеседование для оценки профессиональных навыков. Подчиняется внутреннему распорядку моей компании, делает то, что я скажу, в рамках должностных обязанностей и инструкций. Плачу я за его жопочасы. Аутсорс — сотрудник сторонней компании, которого я в жизни могу ни разу не увидеть. Мне вообще пофигу кто он, где и как работает, сколько получает. Деньги я плачу его работодателю за результат его работы. Сотрудник — сотрудник, который работает в моей компании, ну тут вроде как все понятно.
Моя первоочередная задача — получить от сотрудничества максимальную выгоду.
Если мы говорим об аутстафе — мне выгодно чтобы он писал. Мне не выгодно, чтобы он отвлекался на вникание в продукт. Мне нужно получить от него максимум полезного кода за минимальный промежуток времени. Для этого он получает требования, следование которым делают код полезным, а оценку полезности прозрачной и объективной. Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования. Он сдает код на ревью ровно так же как и мои штатные сотрудники, по результатам которого оценивается соответствие кода ТЗ и тем самым требованиям. Выполнил — молодец. Вот тебе следующее ТЗ. Нет — переделать. Снова не справился — прошу его работодателя прислать нового. Все строго по джире, все строго по часам. Я не хочу платить деньги за образование таких сотрудников. Я не хочу платить деньги за их кофебрейки, разглядывание котиков в интернетиках и их присутствие на митапах, где они абсолютно не нужны (ну понятно, все в разумных пределах, я не надсмотрщик над рабами). Я не хочу платить за вникание. Только бизнес, только код, ничего личного.
Если мы говорим об аутсорсе — все сильно проще. Есть то же самое ТЗ. Как правило, чуть более сжатое, поскольку описывает не одну задачу на несколько часиков, а требования к значительной части продукта, либо к продукту в целом. Да, я закладываю время на обсуждения и уточнения этого ТЗ с второй стороной. Я закладываю в бюждет чуть больше чем изначально в договоре (НИКОГДА в моей практике, финальная стоимость не была равна стоимости по договору). Я отдаю ровно те же самые требования, которые получил аутстафер. Я получаю результат. Я оцениваю результат. Я плачу за результат, если он меня устроил. Все. Больше меня ничего не интересует. В продукт должен вникнуть менеджер, с которым я работаю. Или не должен понимать продукт, но должен правильно понимать ТЗ. Будут ли вникать в него программисты той фирмы — мне не важно.
Мой сотрудник: должен знать все те требования к коду наизусть. Еще лучше — интуитивно понимать их. Должен понимать архитектуру, ожидания от продукта и его философию. Должен, потому что у меня просто не хватит времени писать для всех них подробные ТЗ как для аутстаферов. Должен учиться, развиваться, думать. И я готов за это платить, мне это выгодно, поскольку такие сотрудники экономят и мое время, и бюджеты компании, и вообще — главная ценность софтверной фирмы.
Так что все, что описано автором — вполне себе так и должно быть. И не приплетайте сюда говнокод и рассуждения, кто лучше пишет. Это ровным счетом никак не зависит от того, в какой компании работает человек. Это зависит исключительно от его личных качеств и навыков, а также от умения читать требования заказчика, как внутреннего, так и внешнего, и выполнять их. Если заказчик таких требований не предоставил — его проблемы.
И да, фреймворки и кододрочерство тоже к этой проблеме не имеют никакого отношения. Все должно быть строго регламентировано в рамках ТЗ. Аутсорс или аутстаф, меняющие по желанию стек продукта — нонсенс или идиотизм заказчика.
vvpetrov91
23.05.2019 12:43Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования.
Все должно быть строго регламентировано в рамках ТЗ.
Должно-то оно должно, но проблема в том, что в крупных проектах таких ТЗ не существует (я искренне хотел бы в это верить, но факт есть факт — их нет). При интеграциях, при пересечениях логики — на каждом шажке в крупных проектах есть куча нюансов и подводных камней. В своей практике часто вижу как разработчик-пофигист делает все строго по ТЗ, а шаг влево шаг вправо и упало. И ведь с такими и спорить невозможно — они никогда ни в чем не виноваты. Мозговой центр разработки — это разработчик, а не менеджер. И качество делают разработчики. А «максимум полезного кода за минимальный промежуток времени» на практике почти всегда с течением времени приводит к большим затратам бюджета, нежели экономии здесь и сейчасdustd
23.05.2019 13:08Простите, я не знаю как в крупных проектах, я знаю как у меня (на текущий момент — банковская группа). Если те проекты не умеют работать с аутсорсом и аутстафом — пусть не работают. Я — умею. Такой вывод делаю на основании того, что получаю от этого вполне ощутимую прибыль. Именно потому что ТРЕБУЮ делать строго по ТЗ. Если ТЗ написано криво — это только моя ответственность. Если оно написано криво — я получу за те же деньги кучу БЕСПОЛЕЗНОГО кода. Полезный код — это код который легко поддерживается, рефакторится, переиспользуется, автоматизирует бизнес-процессы. Это те требования, которые я к нему предъявляю (точнее результат тех требований). С чего бы он должен приводить к большИм затратам, ну или как минимум, к затратам бОльшим чем код, написанный за большое количество времени? Как тут время вообще коррелируется с качеством? Вы искренне считаете, что "Hello, world!" на который потратили 2 недели будет сильно качественнее чем тот, который смогли написать за 2 минуты? А вам не приходит в голову, что разработчику из вашего примера ТЗ и было написано потому что шаг влево/вправо — и все упадет? Нахрен мне его самодеятельность не нужна в этом случае, я не хочу чтобы что-то падало. От этого страдает бизнес.
vvpetrov91
23.05.2019 14:04Простите, возможно не до конца проникся Вашему трактованию о «полезном коде». Если так, то да. А что касается времени и качества, то услышьте меня, не надо входить в крайности про «Hello, world!». Зачастую менеджеры в основном далеки от разработки. Они видят потребность бизнеса и стремятся во что бы то ни стало реализовать ее максимально быстро, полагая, что внутренняя архитектура проекта — пустая трата времени. И это именно то, с чем я имею дело. И вот этот вот и приводит к обратному Вами трактованию полезного кода и всем прилагающим. У меня есть собственные примеры командной работы, когда из-за таких гонок, итоговый проект выходил на несколько месяцев позже срока. И подобный ущерб очень существенен, он перекрывает все — потеря прибыли за пол года, разработка длилась больше на пол года. В ТЗ же упор обычно делается именно на новую функциональность, и на моей практике, как я уже сказал, в нем никогда не просчитываются все нюансы текущей функциональности, которая развивалась и менялась годами. Не знаю степень сложности Ваших систем, но с тем с чем работаю я — определить все нюансы невозможно до начала ее реализации функциональности. Хоть и ТЗ смотрят несколько человек, перед реализацией. Вот тут и встает вопрос о степени вовлеченности разработчика в процесс и его мотивации — собственно это играет основополагающую роль. Итого — «гонки» менеджеров и пофигизм разработчиков ведут к колоссальным затратам. Возможно наша команда не умеет работать, а Вы умеете, но мы имеем то что имеем. И примеров у меня, к сожалению, много
dustd
23.05.2019 14:30Если менеджер не умеет слышать разработку — это действительно очень печально. Отсутствие архитектуры — еще более печально. Тут я Вас прекрасно понимаю, поскольку у самого вполне себе программерский бэкграунд, и через все это неоднократно проходил. Но разговор изначально не о том. В моем случае ТЗ пишу я САМ. А не менеджер компании аутсорсера ДЛЯ МЕНЯ. Я знаю, на сколько все мои системы и модули завернуты в абстракции, где какие имеют коннекторы и так далее. Я знаю архитектуру, а не менеджер. Именно поэтому, мое ТЗ не оставляет шансов менеджеру-аутсорсеру всунуть мне какашку, которую вы описываете, и которая у меня просто не будет работать, а если и будет — за дополнительные деньги. Я ее просто не приму, не заплачу за нее, и даже не буду париться, выслушивая какой я нехороший, поскольку они вот старались, сроки соблюдали и так далее…
poxvuibr
23.05.2019 16:36В моем случае ТЗ пишу я САМ.
Если ТЗ учитывает особенности реализации проекта, то его очень тяжело написать. У вас много времени отнимает детализация?
dustd
23.05.2019 16:55Слишком. В последнее время трачу на ТЗ и прочую документацию (за исключением пользовательских мануалов, ими занимаются отдельные люди) до 6 часов в день. В основном, это формализация требований бизнеса (перевод с русского на программерский). Для работы с аутстаферами удалось выделить отдельного человека, иначе вообще кроме бумажек ничего бы не видел. Оставшиеся 2 часа — либо ревью кода, либо живое общение с бизнесом/исполнителями. Кодить времени почти уже нет.
UPD: работа с таск- и баг-трекерами в это время тоже входит.
Peter03
23.05.2019 18:09Было бы интересно услышать мнение с другой стороны. От аутстафера который на вас работает. Особенно неформальное мнение, после того как он ушёл в другое место.
Думаю много интересного для себя могли бы почерпнуть, мнение относительно качества процессов, о личных человеческих сторонах, узнать методики как он вас крутит вокруг одного места.
Если разработчик не вовлечён в процесс и его микроменеджат, то максимальная выгода которую вы от него сможете получить, меньше минимальной в случае когда он вовлечён и искренне заинтересован.
Вам наверное со стороны кажется что вы такой деловой и эффективный, но судя по тому что вы написали и базируясь на многих годах опыта, очень сильно сомнения гложат. Так обычно рассуждают виртуальные менеджеры (wanna be, которые менеджеры на хабре, а не в реале) либо новоделы, кто только-только запрыгнул на это место и пытается быть святее папы римского. Ну или совсем клинические случаи.dustd
24.05.2019 10:19-1А мне глубоко фиолетово, что там думает аутстафер, тем более который уже ушел. Мне глубоко пофигу как он пытается меня вокруг чего-то вертеть. Мне сильно по барабану на Ваше мнение относительно эффективности разработчика при микроменеджменте и при вовлеченности. Мне искренне начихать на ваши сомнения относительно моей должности, и на то, на чем они основаны.
А вот размер моей годовой премии меня очень даже интересует. И зависит она исключительно от моего личного KPI, который, во многом, зависит от KPI моего подразделения. И если судить именно по ней — я просто сама деловитость и эффективность.
С уважением, директор департамента развития банковских технологий, ПАО "............"
StriganovSergey
23.05.2019 11:38Быть или не быть?
Что благородней: стать расходником-тонером в принтере, печатающей для Хозяина Деньги, тонером, который меняют каждые три месяца, и которому все равно что и на чем печатать, или стать принтером, печатающим для того же Хозяина те же Деньги?
Принтер меняют гораздо реже, а кроме того, у принтера есть свои собственные предпочтения по размеру и качеству бумаги и прочие интересные особенности.
Стать Хозяином ни в статье, ни в комментах — не обсуждается.
LLL0
23.05.2019 15:52-2в этой статье заметил разницу только между разработчиками и разработчиками словоблудами пока только. вода водой
Maccimo
24.05.2019 04:28+1Однажды мы с командой проводили тех-интервью, кандидат неплохо шарил, но мы решили, что он нам не подходит только потому, что пришел из продуктовой компании.
Эпизод V: Гребец наносит ответный удар.
EvgeniiR
В аутстаффе/аутсорсе действительно выделяют время (недели!), на рефакторинг и приглаживание кода?
У меня есть ощущение что настрой «мне нет дела что там за продукт, главное что код пишу» очень близок к настрою «мне без разницы какой там код, и насколько хороший код я пишу, деньги то получаю»
4e1
Выделяют, даже заказчики-жлобы, если очень аргументированно, долго и настойчиво долбать этим всех подряд. Аргумент «вот мы сделали, как вы просили по-быстренькому, а там багов вылезло, как мы вас и предупреждали» работает бронебойно.
rakshazi
Ага, но нужно помнить про самую важную часть: «долго и настойчиво долбать» — иначе ничего не случится
0xd34df00d
По личному опыту — нет. Продукт неважен, важен технологический челлендж (то есть, что код пишу, да). Но именно потому, что важен челлендж, важно, какой именно там код и насколько хороший код я пишу.