Pull to refresh

Comments 161

В аутстаффе/аутсорсе действительно выделяют время (недели!), на рефакторинг и приглаживание кода?
У меня есть ощущение что настрой «мне нет дела что там за продукт, главное что код пишу» очень близок к настрою «мне без разницы какой там код, и насколько хороший код я пишу, деньги то получаю»
Выделяют, даже заказчики-жлобы, если очень аргументированно, долго и настойчиво долбать этим всех подряд. Аргумент «вот мы сделали, как вы просили по-быстренькому, а там багов вылезло, как мы вас и предупреждали» работает бронебойно.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Автор пишет буковки для компилятора, называя это «кодом». И не понимает зачем это нужно. Лично я понимаю людей, которые работают ради заработка или чтобы помочь другим людям. Но не понимаю тех, кто пишет буковки для компилятора и считает это смыслом
UFO just landed and posted this here

Кто это увидит кроме разраба? Мало того — кто это увидит, хоть кто нибудь кроме того, кто полезет именно в конкретный модуль?
У кода есть цель. Я конечно понимаю, что "эффективные манагеры" могут превратить изначальную цель "сделать людям лучше" в фикцию, но сейчас не о них речь. Сейчас речь о человеке, который вместо того, чтобы решать поставленную задачу — вылизывает код. Да он будет стилистически идеальным, но… какой смысл?
Это, простите, какая-то кодомастурбация — получать оргазм, если код идеальный. Я в принципе признаю за людьми право на извращения — у всех свои слабости — главное чтобы это не становилось манией, что уже опасно.


Даже умные мозги для унитаза должны делать то, что этому унитазу положено (не знаю никогда не сталкивался с умными унитазами) — т.е. у них (мозгов) есть цель. Т.е. даже у умного унитаза — есть цель. А тут некий разработчик говорит нам, что цель не важна.

UFO just landed and posted this here

У хобби есть результат — получение удовольствия, расслабление, отдых.
За код же нам — платят. Т.е. заказчик заказывает конкретное ему нужное решение. Это решение мало кто видит, но заказчик обычно платит за две вещи:


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

В статье же я увидел — код ради кода. Ничего не скажу против того, что красиво написанный код — приятно читать. Это факт — приятно. Но если сравнить "быстро внедрённое решение" приносящее в результате доход, удовлетворение от выполненной задачи или возможность перейти на новые задачи и стать выше уровнем со 125-тью возможностями красиво написать "Hello, world!" на 15 различных языках и фреймворках и все они будут одинаково прекрасны — то… "Hello, world!" — бесполезен.
К тому ж эпопея с "Hello, world!" нарушает основной принцип программирования — KIS.

Если человек умеет писать код ради кода так, чтобы получалось решение удовлетворяющее заказчика за разумное для заказчика время, то разве так уж важно что разработчик при этом пишет код ради кода и его совершенно не волнует продукт и его судьба? Пока всех все устраивает нет никакой проблемы — один решает свои мысленные задачки создавая идеальный в его понимании код в условиях ограниченных ресурсов, другой платит деньги и получает работающий результат. Кому плохо то?

Если человек пишет код красиво сразу или имеет время на его облагораживание (что случается реже) — это прекрасно.
Но в статье я увидел посыл: задача ничто, код — всё. А эта позиция — ущербна как любая граничная. Баланс он где-то посерединке.
Вышел новый фреймворк? Давайте перепишем проект на Asp.NET MVC под Angular? Плевать что послезавтра релиз, плевать, что большинство команды знает Angular только по названию — внедряем и переписываем! Это путь в бесконечный процесс, за которым… Да даже в резюме нечего написать. Ведь одно дело — перечень решённых задач, а другое — прекрасно выглядящий код, который тем не менее не делает ничего ибо не закончен.
Сколько проектов не вышло, сколько команд распалось из-за того, что хотели сделать "сразу как надо" и облагораживали решение, а в это время конкуренты быстро выпускали продукт и допиливали в процессе?

Конечно нужен баланс, я не спорю. Я скорее о том, что если у автора при его позиции про «код — всё» получается завершать задачи, то вполне нормальная у него позиция. Это же разные вещи, хоть и связанные — отношение к задаче и умение задачу завершать. И автор там в какой-то момент пишет что завершать задачу и клепать готовые фичи он умеет.
Зато, вы будете уникальны, ибо после этого переписывания уже никто ничего не будет понимать в коде )
Типичный индусский подход, для секьюретизации рабочего места.
Вы сейчас путаете теплое с мягким. Давайте посмотрим на это со стороны… Ну хотя бы Product Owner`а — итак, что нам надо: продукт, который будет приносить людям радость, а люди за эту радость будут платить. Желательно получить этот продукт как можно быстрее и как можно дешевле. При этом все задачи на проекте, как правило, делятся на 2 категории: на подумать и на запилить. При этом задачи «на подумать» — это не просто бейн-сторм нон-стоп. Это эксперименты, неудачи, поиски. Для этого хороши именно продуктовые программеры. Задачи на «запилить» — четко регламентированные, хорошо описанные, и, в большинстве случаев, абсолютно тупые. От забора и до обеда. Думать не надо. Нужно просто писать код. Хороший, легко читаемый и легко поддерживаемый код. И вот тут себя галерные рабы покажут гораздо лучше. Поскольку будут и эффективнее и дешевле. В итоге, хороший PO будет совмещать.

Не сможет, потому что в (по статье) команду не нанимают людей с альтернативной точкой зрения на продукт. Фанаты кодо- и фреймодрочерства — просто не примут человека с иным мышлением.

А причем тут вообще фанаты фреймо- и кододрочерства? Я, как лид, ПМ, ПО и тот человек, который отвечает за продукт перед бизнесом (и фреймо-кододрочер по совместительству) должен прекрасно понимать, когда можно менять инструментарий, когда это сделать категорически нужно, а когда категорически нельзя идти на поводу таких товарищей. Вы взяли на работу людей, которые не в состоянии работать над продуктом, потому что занимаются фигней и исключительно сменой стека — это ваши проблемы. Вы отдали что-то аутстаферу, не написав должным образом ТЗ (в котором должен быть указан стек), Code Style и Code Convenction? Это снова ваши проблемы. Кстати, автор кододрочерами называет именно аутстаферов, а не продуктовиков… И у аутстафера не должно быть НИКАКОЙ точки зрения на продукт. Ему, с точки зрения ПМ`а и ПО`ра, думать вообще вредно.

У аутстафера — действительно не может быть никакой точки зрения на продукт, просто потому что ваш продукт — это не его продукт. Его продукт — это та часть работы, что ему поручена. Теперь представим ситуацию вы вычленили часть работы, что можно выполнить вне контекста, составили ТЗ, согласовали и аутстафер начал выполнять-выполнять-выполнять… Один фреймворк, смена версии языка, новый паттерн архитектурный. Это вместо того, чтобы написать, оттестировать, рефакторнуть и сдать работу.
Допускаю, что с вашей точки зрения это может быть приемлемым — ведь интерфейс соблюдается, а у вас дофига времени. Но как часто в бизнесе бывает дофига времени? А если учесть, что оплата у аутстафера может быть почасовая — за его эксперименты и обучение платите вы.


Выбирать то в любом случае вам, как тому, кто платит.

Вы все исключительно верно написали. Оплата аутстаферов — как правило посуточная. Моя задача — выжать его за эти сутки по максимуму. Вы думаете, я оставлю ему время на эксперименты с фреймворками? Я оцениваю время на задачу, согласовываю с ним — все, арбайтен. Задачи для аутстафера в принципе не должны превышать 4 часа.

UFO just landed and posted this here
> заказчик заказывает конкретное ему нужное решение.

Заказчик обычно даже не знает что ему нужно. Он, иногда, знает как оно должно выглядеть. Мысль, например, о том, что код должен быть поддерживаемым, а не написанным на скорость, приходит потом и не всем. Он такой, может, и не всегда нужен, но этого заказчик тоже не понимает.

И, внезапно, быстро внедренное решение оказывается несовместимым с реальностью, вместо дохода приносит остановку бизнеса и необходимость срочных доработок.

В общем, за заказчика ТЗ додумывать надо. А то этот бедолага разориться раньше, чем осознает и научится. А тогда он с повторными заказами не придет.

Ну это уж проблема постановки и интерпретации задач, но никак не идеальности и чистоты кода. И для того, чтобы постановка и интерпретация задач была нормальной с заказчиком должны работать совсем другие люди, которые код — писали когда-то в далёкой юности, но вместе с тем знают азы его написания, иначе вообще не команда а фигня какая-то (утрирую, конечно).

а в каких единицах у вас в постановке степень необходимой чистоты кода указывается?

Чисто субъективно — лично я считаю тот код чистым который удовлетворяет условию:


  1. Делает то что нужно
  2. Легко читается и понимается
  3. От взгляда на него — не хочется найти и убить предыдущего писателя.
1) это не про чистоту
2) Легко читается и понимается ВАМИ, субъективно
3) то есть, пока код только ваш — он идеален :)

В общем, вы сами решаете какой код писать
  1. Какой смысл в красивом коде, если он ничего не делает? Сам смысл кода — это красивое и элегантное (по возможности) решение задачи.
  2. Да это субъективное понятие
  3. Нет. Я не пишу идеальный код. Ииногда даже костылю, увы. Но и не лицемерю на эту тему. Понятие красоты — действительно у каждого своё.

Да я решаю. И вы — если вы программист. И любой другой программист решает. Главное следовать одному незыблемому правилу — "не делать из едыкода культа" О.Бендер :).

Понятие красоты — действительно у каждого своё.
— нет, красота это симметрия, она нравится любому человеческому мозгу т.к. ее проще запомнить и легче воспринимать, т.к образы стуктурны и воспроизводятся отражением, нужно в разы меньше усилий
т.о. это объективное понятие

Не соглашусь. Стандарты красоты у всех разные и зависят как от человека так и от культурных традиций: кто-то получает эстетическое удовольствие от созерцания абстракионизма, а кто-то — называет абстракционизм мазнёй.
На небольшом острове Тонга красотой считаются большие физические размеры. Причём настолько что у первых "красавиц" острова — трудности с передвижением. Я считаю такую "красоту" — сомнительной.

> 1. Делает то что нужно
vs
> 1. Какой смысл в красивом коде, если он ничего не делает? Сам смысл кода — это красивое и элегантное (по возможности) решение задачи.

что-то вы сами с собой спорить начали

вы делаете элегантное, на сколько считаете нужным, автор делает на сколько считаете нужным. Почему вы делаете как надо, а автору приписываете культ?

Противоречия нет, ключевое — решение задачи. Если оно красивое и элегантное то — это прекрасно. Если не очень, но есть время на приведение в красивость и элегантность — тоже хорошо.

решение задачи != чистый код
чистый код != решение задачи
ничего не делает != !(делает то, что нужно)

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

Логично. И что?
Т.е. вы спросили меня какой код я считаю чистым? Я — привёл пример субъективных критериев — и теперь что вы пытаетесь мне доказать? Что критерии субъективны? Так это факт — ибо они мои. Кому-то и говнокод — вполне себе код. Главное что задача решена.
Я считаю, что код — облагораживать надо, но не возвожу облагораживание кода в абсолют. Также моё мнение, что не стоит прыгать с фреймворка на фреймворк, если до релиза рукой подать, а новый фреймворк может преподнести незапланированный сюрприз.

> Т.е. вы спросили меня какой код я считаю чистым?

И получил ответ «Главное что задача решена.». Я не то, что бы пытаюсь убедить, но это не ответ на мой вопрос. Нет у вас ответа лучше — чтож…
UFO just landed and posted this here
Ну это нужно другим людям. Когда эту фичу будут модифицировать/расширять/поддерживать/писать связанный или похожий функционал, то придёт радостная команда разработчиков и менеджеров, и им нужно будет что-то с этим кодом сделат, сделать быстро, не наделать кучу багов, и чтобы проект не провалился.

Вот для них.
Как я понимаю, работа в аутстаффе/аутсорсе именно для зарабатывания денег.
Вы не поверите, но ЛЮБАЯ работа — именно для зарабатывания денег. Если нет — это хобби ))

Тут на доу недавно HR говорила что плохо доверять бездушному ИИ такую задачу как выбор персонала. Мол не этично. Нуну

Какой-то у меня противоположный автору опыт. При работе в аутстаф компании, я видел код намного хуже. Хотя и сам и пытался рефакторить. Но руководству то это не особо интересно. Им интересней быстрей продать проект. Потом перешел в продуктовую компанию и отношение к продукту было координально другое. Ты делаешь продукт, который приносит компании деньги. Тебе не просто надо написать код, а от того как этот код будет работать дальше — будет зависеть сколько заработает компания (и ты косвенно). Поддерживать потом либо тебе, либо коллеге из соседнего кабинета — на качество кода и архитектуру уже не забьешь.


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

Компании бывают разные и могут находится на разных этапах, стартапы обычно говнокодят ради быстрого видимого результата, а потом если бизнес попёр (и хватает мудрости основателей) приходит время когда для стабильности этого бизнеса надо рефакторить.
приходит время когда для стабильности этого бизнеса надо рефакторить

И на это забивается болт, ведь для рефактора времени нет, а большому бизнесу нужны новые фичи здесь и сейчас :)
Чаще всего да, поэтому в какой-то момент монстр начинает буксовать в говнокоде и приходят молодые делающие более модный продукт и цикл повторяется.
Мой опыт аналогичен вашему — аутстаф пишет значительно хуже, чем внутренняя команда. В большинстве случаев это происходит по двум причинам — они даже не пытаются вникнуть в бизнес-процесс и у них почти всегда горят сроки, которые тяжело подвинуть ибо бюджет фиксирован. Первая причина конечно утрирована, но часто приходилось видеть технически неверные решения, которые принимались просто из за отсутствия информации/понимания бизнес-процесса.

P.S. Сам сейчас работаю как раз в аутстаффе. И после продуктовой(внутри компании) разработки мне больше всего не хватает довольных пользователей. Это же двойное наслаждение — «о как красиво я решил технически!» и «насколько легче стало жить пользователям».
Писал чуть выше, напишу еще раз: если аутстаф-разработчику приходится вникать в бизнес-процессы компании — компания не выстроила свои бизнес-процессы. В итоге, будет как вы пишете: говнокод и полная неудовлетворенность заказчиком/заказчика. Если компания четко знает что делать внутри, а что можно и нужно отдать на аутсорс/аутстаф/фриланс — все будут довольны. Не аутстафер должен формализовать процессы компании, а компания должна их очень четко описать. Исключения — аудит и оптимизация процессов, либо внедрения каких-либо CRM, когда приходит специально обученный аутстафер, и все это формализует. Разработчиком он, как правило, не является от слова совсем.
Вы пишите про «правильного» заказчика, у которого есть желание и ресурсы самостоятельно формализовать процессы и написать ТЗ для разработчиков. Или хотя бы проверить, что делает аутсорсер. Я, к сожалению, работаю у неправильных заказчиков, как внутри, так и в качестве аутстаффера. У них ТЗ, точнее хотелка, которую они гордо зовут ТЗ, обычно умещается на пару страниц А4, где суть укладывается во фразу «автоматизировать процесс XXX».
Из последнего, проводил ревью решения написанного аутсорсерами, выдал вердикт — «ужас, ужас, нельзя такое в прод». Хотя все работает, но при малейшем изменении может сломаться. Заказчик сказал — «ну работает же, а сроки уже прошли, давайте в прод».
Остается надеется, что правильные заказчики существуют, как и правильные аутсорсеры, но я пока их не видел, и до выплаты ипотеки вряд ли увижу :-).

У нас самый ээ… как бы вежливо сказать… лютый и код написан аутстаф-командой. Я мало с ними работал, но они копали от забора и до обеда. В итоге там адская лапша с размазыванием функциональности между модулям.

Хотя я и не люблю кровавый энтерпрайз, но автор, пытаясь описать динамичность "галер", описал его так, что вышло только хуже.
Такое ощущение, что это они — те самые люди, которые чисто из-за хайпа готовы прикрутить блокчейн, микросерисы, кафку, пюрефку, просто "А вдруг?"

UFO just landed and posted this here
Потом решили да сменили пол.
Желаю автору никогда не попасть к хирургу, для которого неважен результат операции, но «вот вчера купил такой клевый скальпель, сегодня им попробую резать.

Аналогия не очень. Хорошей аналогией был бы врач, которому важно только чтобы операция прошла идеально, а насколько улучшится от этого жизнь пациента и как он будет рад — это хирурга уже не интересует.

UFO just landed and posted this here
А это, кстати, плохой врач?

С моей точки зрения, это очень хороший врач.


Ведь он же старается сделать операцию идеально.

Вот поэтому и хороший.

Идеально — это «пациент не умер на столе»? А что там с ним после выписки произошло — нас не волнует? ;)
Идеально — это «пациент не умер на столе»?

Вы думаете так хирурги определяют идеальную операцию?

Ну, собственно, с точки зрения минздрава — да. + количество операций на единицу времени. + статьи (в свободное от остального) время. + еще всякое разное не функциональное — и это все — определяет насколько специалист хорош. (на всякий случай еще раз — это не мое определение хорошести).

И если вернутся к оригинальной теме, то хороший девелопер (в данном контексте) это будет мифическая сущность, которая фигачит фичи сотнями, учачвствует во всех конференциях мира с докладами, не допускает багов во время деплоймента в прод, и которая вообще не в курсе что именно она там надевелопила и зачем…
Ну, собственно, с точки зрения минздрава — да.

И вы думаете, что с точки зрения хирургов — тоже да?

Похоже на разработку с точки зрения бизнеса. Функциональность есть + больше фичт за единицу времени.


Описываемые здесь кододрочеры имеются другие приоритеты

Желаю автору никогда не попасть к хирургу, для которого неважен результат операции, но «вот вчера купил такой клевый скальпель, сегодня им попробую резать.


И знаете, я бы пошел к этому хирургу, который вместо скальпеля использует лапароскопию — тот самый «новый скальпель».
UFO just landed and posted this here
Если вы пришли на операцию, то наверное не просто так. Но комментатор выше рассуждает по логике «старое — оно же доброе, хорошее, проверенное. Оно же старое, как оно может быть плохим? А все новое — сырое и глючное». А иначе его сравнение не имеет смысла. Не все старое хорошее и не все новое плохое и вообще никакой связи между этим нет. Как и нет смысла пользоваться старым инструментарием, если есть новый (хорошо, более новый) с доказанным преимуществом.

Тут вопрос не в старом-новом, а в подходе к операции. Что важнее хирургу — живой пациент или инструмент попробовать...

UFO just landed and posted this here
Не соглашусь с вашим выводом про квалификацию.
Мне кажется, автор просто не успел познать радость создания продукта решающего чьи-то проблемы. А без подобной мотивации реально скучно на одном проекте сидеть больше чем N месяцев. Новые технологии/языки/фреймворки просто позволяют бороться с этой скукой, потому что рождают вызов по их освоению.
Насколько я понял, он успел сделать какой-то инструмент логирования для роботов, но радости ему это не принесло. Вот если бы это самое логирование помогло какую-нибудь реально возникшую проблему решить, то автор может быть и проникся бы.
UFO just landed and posted this here
Про хирургов Вы не поверите, но от матери слышал не раз про коллег, которым материал для диссера было интереснее писать, чем вылечивать пациента. Поэтому и обследования назначались инвазивные и долгие, даже если они объективно пациенту были не особо нужны по показаниям его заболеваний, но очень информативны были для наполнения диссера.
UFO just landed and posted this here
Это все идет от поверхностности. Чтобы разобраться в технологии и понять как правильно и можно ли использовать ее в проекте — нужны значительные временные затраты. А на аутстафе/аутсорсе нет на это времени. Им нужно здесь и сейчас и продать себя подороже, выкрикивая побольше заклинаний «микросервис», «кафка» или так делал амазон, гугл, фейсбук
Ну не только из-за хайпа, еще и для личного самообразования. Готовый полигон, надо только работодателя убедить, что эта технология очень важна для развития продукта и стоит полгода на переписывание с нуля.
На днях друг хвастался мне, что завернул на собесе чувака, который работал только в аутстафах

Однажды мы с командой проводили тех-интервью, кандидат неплохо шарил, но мы решили, что он нам не подходит только потому, что пришел из продуктовой компании


Адекватность при приёме на работу: уровень «дно донское». Кандидатам очень повезло, что их не наняли и что они не работают бок о бок с такими нанимающими людьми.
Адекватность, действительно, отсутствует.
Зачем вызывать на собеседование человека, о котором заранее известно, что он не подходит.
навыдумывали много поводов для отказа

Непонятно, зачем выдумывать. Профессиональнее было бы сказать правду.
Всегда думал, что уровень «сеньор» — означает, что разработчик не только научился писать «совершенный» код и курить любой фреймворк, но и постиг тонкую грань того, когда и как это делать, чтобы и продукт жил, и глазам было не больно в код смотреть.
И с таким видением, как мне кажется, можно одинаково успешно и комфортно работать над продуктом и в аутстафе.
Синьор, это не тот, кто кодит, это тот, кто разрабатывает
Синьор постиг тонкую грань того, что и когда делать
Синьор не пишет на, синьор пишет с использованием
Синьор не будет тащить новомодный фреймворк
Синьор не будет писать на устаревших технологиях
Синьору всё равно что делать
Сеньору важно, что он делает
Синьор понимает предметную область
Синьор не зацикливается на предметной области
Синьор никогда, никогда не напишет что-то, с чем я не согласен
Синьор то, синьор это

Не надоело вам?
UFO just landed and posted this here
UFO just landed and posted this here
думаю для бизнеса, это тот, кто приносит больше выгоды в конвертируемом для компании выражении и получает больше чем джуниор

Размер внутренней ответственности решает. Можешь поддерживать проект так, что б он не рухнул. И свалить не на кого. Джуниор может отмазаться и чинить будет синьор. Синьор может попробовать отмазаться, но чинить всё равно ему (а кому ещё, больше некому).


Формально это не измеримо, поэтому оценивают навыки.

Ну, не смотря на сарказм, обычно так и бывает :)
Остальные критерии достаточно субъективны и зависят от многих факторов, например от компании и/или специфики разработки.
Синьор не будет строчить статейки с плохо обоснованным изложением непопулярных мнений ради хайпа.

Слышал про такой вариант:
Джун — мало ответственности и поэтому за ним нужно следить
Мидл — тот за кем не нужно следить, он сам может за себя постоять
Сеньор — тот кто ответственен за других и себя


Что думаете?

Сеньор — тот кто ответственен за других и себя

Это тимлид.
Эта квалификация параллельна джуно-сеньорской.
Мой вариант:
Джун — может накодить
Мидл — может еще и задизайнить
Сеньор — еще и понимает все аспекты решаемой проблемы
Джун — тот кто решает простые проблемы сложным путем.
Мидл — тот кто решает простые проблемы простым путем, сложные сложным.
Сеньер — тот кто решает сложные проблемы простым путем
На самом деле так:
— Джуниор думает, что всё знает.
— Мидл знает, что ничего не знает.
— Сеньор знает, что ничего не знает, но ему уже всё равно.
По моему впечатлению
Сеньор знает, что никто ничего не знает.
Зачем отступать от классики?

Джун должен знать всё.
Мидл должен знать в какой книге находится всё, что знает джун.
Сеньор должен знать где находится мидл.
Мидл — тот, кто может сделать проект в одиночку. Соответственно, джун — не может, сеньор — не хочет.
больше всего похоже на правду)
Джун — лейтенант
Миддл — старший лейтенант
Сеньор — капитан
Тимлид — майор
дух, слон, дед, дембель

у каждой компании… да что там — у каждого начальника / менеджера свое видение сениора, мида и джуна. много я уж этих матриц соответствия и списков критериев насмотрелся

Имеет смысл в описании вакансии указывать: разработчикам из аутстафа (или продуктовой компании) просьба не беспокоиться.
Или же на этапе скрининг интервью не пропускать дальше неугодных.
Так можно сохранить своё и чужое время.
UFO just landed and posted this here
середину найти трудно, но есть пара но…
1) есть риск 5+ лет просидеть на одном проекте в аутсорсе и на древнем стеке, иначе, если постоянно менять аутсорс проекты (а для этого и компании кстати) есть риск стать эникейщиком, так и не научившись делать что-то стоящее от и до
2) почему страдает качество, посыл не мой:
Аутсорсер живёт за счёт разницы между зарплатой и ценой продажи человековремени — поэтому игра, с некоторыми упрощениями, имеет нулевую сумму, а зарплата — конкретный потолок. В продуктовике экономика другая — потери из-за высокой текучки (или даже необязательно высокой — если уходят сотрудники высокого уровня компетенции) существенны настолько, что «как можно меньше» может быть намного выше рынка.
UFO just landed and posted this here
корректирует самооценку

Ну совсем-то не загибайте, Хабр это технический, а не фантастический ресурс)
Я тогда не придал этому значения, а сейчас понял — похоже, разработчики, которых по три раза за год продают на чужие проекты, и разработчики, которые пять лет фигачат один продукт — совсем разные профессионалы. Обстоятельно покопавшись в себе, я понял, что не просто отношу себя к первым, но и подсознательно презираю людей, которые больше двух лет работают над одним проектом.

Возможно, этому виной плохие примеры. Одна продуктовая фирма, где я работал, использовала C# 2.0. ДВА НОЛЬ. Аргументировали они просто: проект большой, если переносить его на новую версию, наплодим кучу багов. И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.


А вот тут непонятно.

Если «по три раза в год попадать на на очередные продукты», то эти продукты — новые, все как один?

В том время как аутстафная разработка — это всего лишь разработка продуктов корпораций силами внешних специалистов.

Откуда там по 3 раза в год новые технологии?
Ведь это такие же «долгоиграющие проекты».

Исключения в виде «коротких» проектов бывают. Но они бывают и в продуктовых и в аутстафных же.

Приходит тело на проект. Плюется, что за говнокод. Начинает переписывать на новый чудо фреймворк. Переписав процентов 5 несчастного легаси, понятно, что самой понятной его части, через пару месяцев, ибо нервы не выдерживают, уходит на другой проект. На его место берут новое тело. Которое плюется, что за говнокод… За год у всех в резюме появляется опыт работы с чудо фреймворком и по нескольку проектов за плечами.

Так же наблюдаю подобное!
Выход: работает — не трогай, для нового — пиши новый код, если надо изменить старое сначала дублируй в новое место и применяй tick-tock принцип для уменьшения долга.
Главное этот процесс на рельсы поставить и всем объяснить, новичкам — дважды.

Ситуация в статье просто описывает очевидное — мы все разные, а подбор кадров дело тонкое, кого наберешь — так и поплывешь. В разные моменты проекта нужны разные роли от сотрудников — это тоже надо понимать, поэтому лояльность сотрудников очень важна, а это в резюме увидеть можно.
UFO just landed and posted this here
и разобрался в изначальной проблеме которая решалась первым костылем и вместо нагромождения костылей сделал элементарную правку буквально в пару строчек, но на все про все ушло 3 дня — уволили.


Не верю.
Ну премию могли бы не дать — это верю.

Сейчас дефицит квалифицированных — просто так не разбрасываются теми, кто действительно может решить проблему.

Что-то вы не договаривайте.
Некомпетентность это штука вечная. Мы не можем знать что за контора и что за специалисты там были. Если контора привыкла к костылям — они вполне могли и не понять «души прекрасные порывы».
Решить проблему и «решить» проблему — две большие разницы, но для пользователя и зачастую для заказчика разницы никакой. Для не технического манагера тоже разницы никакой. Для неквалифицированного тимлида или синьора — тоже никакой. Разница заметна только тем кто понимает, а таких точно меньше чем 100%. Поэтому вполне допускаю что человека могли уволить.
Просто если товарищ реально рубит, то расстраиваться точно не стоит. Найдет правильное место с правильными людьми и правильными проектами и будет ему счастье. А это просто эпизод на который и внимания то обращать особо не стоит.
UFO just landed and posted this here
применяй tick-tock принцип
Вот вы так пишете, будто это уже широко известный термин в методологиях разработки софта.
Я погуглил — весь инет завален описанием стратегии выпуска микропроцессоров (тик — микроархитектура, так — техпроцесс), каковое значение я в первую очередь и вспомнил, но не смог сообразить, как это можно распространить на рассматриваемую область.

И только отдельными вкраплениями в поисковой выдаче все же нашлись статьи про чередование «изменение функциональности — наведение порядка». Например, "The Tick-Tock Innovation Model Applied to Agile Methodology". (Привожу ссылку для тех читателей комментов, кто как и я, первый раз встречает этот термин применительно к разработке софта).

Вообще, хороший принцип, и довольно универсальный и очевидный — «есть пауза — наведи порядок». Вопрос только в наличии этих пауз. Если приходится постоянно гнать функциональность, становится не до ликвидации долга. Как говорится, «некогда пилу точить — пилить надо!» Конечно, надо бы всё же выискивать такую возможность, буквально выгрызать… но не всегда получается.

Вон и ниже в комментах пишут:
за все время ни в одной компании не было статьи расходов на рефакторинг и годную модернизацию кода

начиналось, наверное, как у большинства: фриланс, чем не аутстаф (только сам себе менеджер, директор, етс.), далее случилось счастье — в течении многих лет основная работа в продуктовой компании, за все время, по дороге, и с продуктовыми разными работал, и аутстаф, да все не по душе последнее.

Если в продуктовой у тебя заслуженный авторитет (а не из раздутого резюме): волю дают принимать важные архитектурные решения, плотно участвовать и корректировать технологический вектор развития продукта и не лепить блокчейны, кафки, амазоны там где это неумесно, экономя расходы аппаратные и человеко\часы.

Но за все время ни в одной компании не было статьи расходов на рефакторинг и годную модернизацию кода.

В прошлом году одна из аутстаф-компании на меня обиделась и нежно выгнала, або тот проект который хотели взять планировал чудовищный стек технологий на диких условиях, когда заказчик требует отчет утром (план), вечером — результат (и не сколько годных коммитов), + активный чат со ВСЕМИ членами команды (человек шесть)… Менеджеры очень хотели этот проект из-за огромного бюджета. На том и разошлись…

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

ЗЫ: не люблю эти ваши собеседования… там 90% треш… знакомый проходил недавно на позицию middle nodeJs — не прошел, не знал чего-то там по html5. )
Менеджеры очень хотели этот проект из-за огромного бюджета. На том и разошлись…

А вы не хотели этот проект ради денег?
нет, овнеры\коовнеры изначально смотрели на проект как на дойную корову, и если сначала пытался донести каким образом можно добиться результат, после слов моего руководства: «просто будешь делать какие-нибудь комиты и активность в чате..» и «игнорируй его, ничего не отвечай» (спустя обещанных 2 часа со стороны моего руководства заказчику) — достаточно было аргументов твердо решить не участвовать.

кроме того, от геморности проекта ставка не меняется, более того, в этой компании овер-тайм не учитывается, а вдруг часов не хватает — минусуют с зп (по часах ставку определяют), и чем меньше рабочих дней в месяце — тем выше стоимость профуканного часа… и другие странные вещи…

аутстаф )

у каждого свой опыт.
Хочется замолвить слово за людей, которые вникают в суть проекта. За тех, кому интересно что нужно сделать и главное для чего (а соответственно как быстро и насколько вдумчиво), а не только как это сделать технически.

Осторожно, много букв.

Я работаю в стартапе на удалёнке, уровней абстракции между мной и заказчиком — ноль. То есть он мне пишет в скайп что он хочет видеть, мы где-то полчасика беседуем если я чего-то не понял, после чего он уходит на какие-то свои митинги. К концу дня он возвращается и обычно видит всё, что хотел.
Бывают конечно ещё сложносоставные задачи, которые разбиваются на «спринт» по тематике — то есть создаём эпик, начинаем делать первую задачу в понедельник, в пятницу всё работает и деплоится на прод (иногда деплоится в следующий понедельник). Спринт в кавычках, т.к. методологиями по понятной причине никто не заморачивается.

Поначалу меня очень смущало, когда он внезапно с описания задачи переходил на описание своего бизнеса и пересказывания митингов. Но потом я понял, что в общем-то это позволяет мне одному выполнять задачи не менее эффективно, чем это делала команда из пяти человек до меня (полусуществующий БА, два фронтенда, два бекенда). При том что этих пять человек заказчику приходилось микроменеджить лично (вплоть до описания полей в БД для бекенда — как написано, так и сделают, даже если это было набросано за пару секунд и является примером, а так откровенным бредом). Потому их и уволили, собственно, а я плавно перешёл из QA-автоматизации в разработку — сначала вынужденно (пока искал работу), а потом з/п подняли и таки остался.

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

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

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

А про отношение вида «состояние проекта в джире важнее, чем в реальности»…
Ну тут вообще уже нечего сказать. Воспитывавшие меня люди такое называли «подстава». Чисто по-человечески так делать нехорошо, если конечно заказчик со своей стороны поводов не давал.

P.S. По работе программирую на трёх языках стабильно и ещё около четырёх знаю по верхам на уровне «увязать вместе чтобы работало» и «понять шо ж там сломалось и почему». Также имею опыт работы с библиотеками, по которым документации нет и не будет, зато есть высокоуровневый диздок или вообще научная публикация в PDF с кучей матана внутри. Но собеседование на разработку скорее всего не пройду, потому что людям нужно, чтобы я на бумажке по памяти прогал с использованием новейших фреймворков :)
И именно такие требования на собеседованиях и появляются из-за засилья аутстафферов, умеющих проходить собесы и концентрирующихся на знании фреймворков, а не на поставленной задаче.
Мы с автором из разных вселенных.
Я люблю программирование потому, что программы облегчают труд людей.
И радуюсь, когда у меня получается новая классная фича.
Очередная статья, полностью построенная на уловке «соломенное чучело». Мда.
о чем вообще статья? о том как «мы отказываем программистам в работе попивая виски в 14.00»?
что я сейчас прочел?
Автор просто нашел себе нишу, чтобы плодить статьи и закрывать потребности во внимании. Ничего особенного.
Так сложилось что мой опыт где-то 50/50. Причём побывал в нескольких аутсорс и нескольких продуктовых компаниях.

И там и там я видел плохой код, и там и там были проблемы с менеджементом и мамонты технологические и т.п.

Но деление между аутсорс и продукт есть — но оно заключается в личных предпочтениях. Кому-то Интересно постоянно что-то новое, новые подходы/языки/проекты и они хотят драйва. А кому-то интересно укреплять базу, развиваться в глубь. Это как кататься на мотоцикле, прыгать с Тарзанки/парашюта и т.д. Против хождения в одно и тоже места условно каждый день (например смотреть закат).

Но поверьте — специалисты хорошие есть везде, и просиживатели штанов тоже.

Я себя отношу больше к продуктовикам — мне база важнее чем технологии умирающие быстрее чем проект. но это не значит что я буду сидеть на старом языке или не использовать хороший Фреймворк (и точно не значит, что я не в курсе новинок). Просто перед использованием нужно задать вопрос — а что мне это даст? И только если плюсы перевешивают минусы, только тогда использовать.

Но по факту, при смене работы и при приеме на работу я ни когда не смотрю на продукт/аутсорс — все зависит от компании/директора/коллектива.

Если в продуктовую команду на собес приходит человек и с горящими глазами рассказывает как он за год пользовался 50 технологиями, то обязательно задам вопрос — «а ты уверен, что хочешь к нам? У нас не будет кучи технологий, зато будут сложные архитектурные задачи.», а человек в праве сам решать интересно ему это или нет.
Если в аутсорс компанию приходит человек, но ничего не слышал о современных подходах, то также возникает вопрос — «а ты готов постоянно развиваться вширь?», и также человек должен решать сам.

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

Снова много букв…

По своему опыту могу сказать, что да в продуктовых компаниях из года в год делаешь один и тот же код из продукта в продукт, переиспользуешь уже готовые и проверенные решения, хоть и основанные на "старых" технологиях. И это не потому что разработчики не хотят использовать новое, а потому что код, проверен временем, отлинтован, юнит тестирован, проверифицирован, и проревьин. Он надежен, и смысл тратить ресурсы и время на тоже самое, но по современному, нет. Это потенциально занесет ошибки.
Мой опыт говорит, что код продуктовых компаний намного чище и надежнее.

выныривает из аврала и суеты
Черт, а что уже пятница? Не успел все комменты прочитать — так какие же фломастеры красивее других?
Он рассказывал не как продукт сделан, а что продукт делает для людей. У нас спрашивал, что мы делаем, а не как и с помощью чего. Мы, конечно не говорили друг другу: «Ему важен продукт, а должно быть насрать», но были единодушны в своем нежелании работать с ним, и навыдумывали много поводов для отказа.

Зато результатами его труда люди пользуются добровольно.

Да и по теме статьи. Непонятно, почему на на аутстафе людям должно быть не насрать на качество кода. Наоборот время нахождения человека на проекте в аутстафе должно быть меньше. Поддерживать их говнокод другим.
Что показательно код, который я видел после аутстаферов действительно был на новом стеке React+Redux+TS. И по нему было видно, что великий комбинатор писал под браузер второй раз в жизни.
Из увиденного как унаследованного так и попавшего на ревью от аутстаферов, которых прислали нам помочь
  • три await подряд, ни один из них результаты предыдущих не использовал
  • человек мутирует в течение простыни реактовский стейт, затем делает this.setState({...this.state}
  • тип данных приходящий от сервера отличается от типа внутреннего представления клиента несколькими полями, при обращении к ним объект приводился к any

Зато будьте уверены у всех в резюме будет React+Redux+TS
Тут, к сожалению, вопрос к компетентности разработчика в целом. Если человек не умеет, его нужно либо учить, либо менять. С аутстафером даже проще в этом плане — не компетентен, до свидания, пришлите другого. Нет всяких ТК РФ и прочего, это не ваш сотрудник. В остальном — ревью кода проводится одинаковое что для «своих» продуктовиков, что для «чужих» аутстаферов, говнокод заворачивается в любом случае.
Автор делает два основополагающих предположения на которых строит все остальное: что аутсорсерам кто-то дает право выбора технологий и методологий и что в продуктовых компаниях работают на древнем стеке.
Очевидно что эти предположения не только не аксиомы, но и верны только для очень частных случаев, и делать из этого глобальные выводы о природе различий между разными типами разработчиков так себе занятие.

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

Вообще мне лично гораздо больше нравится определение «Software Engineer», чем «разработчик». Хорошие программисты — инженеры. А инженер просто не может работать, когда ему «насрать на продукт», иначе это не инженер, а так, чернорабочий на подхвате.
UFO just landed and posted this here
Да все верно подмечено. Как тестировщик, работающий с разными проектами и разными разработчиками уже не первый год, могу сказать что так и есть. Если прогеру пофиг на продукт, то он ВСЕГДА получается говном. А вот кому это заявление кажется странным, тот скорее всего и делает говно.
Как заказчик-продуктовик, работающий с аутстафом последние эдак лет 10, могу со всей ответственностью сказать: говнокод вы получаете не в том случае если прогеру пофиг на продукт, а в том, если вы не дали ему требования, которые необходимо выполнять, чтобы не получилось говнокода. И абсолютно индифферентно, продуктовик или аутстафер этот код будут писать.
"… если вы не дали ему требования, которые необходимо выполнять.." — вот, давайте поговорим об этом. Если у меня есть разработчик, которому надо до мельчайших деталей определять что и как делать, постоянно его контролировать, постоянно самому следить, что неделей назад определенные требования фичера не нужно подкорректитовать после последнего митинга по интеграции, самому проверять что человек не тащит нерелевантные, но кульные фреймворки в репозитарий — это плохой разработчик. Потому что такой микроменеджент простителен (необходим) только зеленому джуниору только что из университета.

Я утверждаю, что разработчик, которому «насрать на продукт», неважно, продуктовик он или аусорсер (хотя среди аутсорсеров таких намного больше), является именно таким плохим разаботчиком. Он будет делать ровно то, что ему сказали, ни на миллиметр меньше, но и не больше ( а если и больше — то не ради продукта, а ради чисто своей выгоды/любопытства). Если вдруг какая-то характеристика фичера вступает в противоречие с другим, бОльшим фичером или просто «опасна» в контексте всего продукта — он этого не увидит и не эскалирует мне. Если его фичер жрет память и CPU в кривых вложенных циклах — ему будет наплевать, потому что никто не определил ему, сколько памяти ему можно брать. Он никогда не придет ко мне и не скажет — а давай вот здесь сделаем вот так, потому что я пил кофе с чуваком из фронтенда, и оказалось, что наши API не учитывают это и это — ему за это не плОтят, ему насрать на продукт. Можно продолжать дальше, но я думаю что мысль ясна.

И вот когда такие разработчики называют себя королями разработки потому что они используют новейшие фреймворки — мне сначала с них смешно, потом грустно, потом они идут искать другое место работы.

Требования — это то, как надо писать код, чтобы его можно было легко читать, поддерживать, рефакторить, переиспользовать. В основном — это выжимка из PSR`ов и "лучших принципов", типа DRY, KISS, SOLID и тд, а также указания где их использовать нельзя в принципе (да, и так бывает). Плюс, мой собственный бред, на тему как надо (будем считать так). Если что — про кривые вложенные циклы там даже написано )))) Всего, в моем случае, это 3 документа на 142 страницы А4 в сумме. Последний раз изменения в эти документы вносились вчера, до этого 2 месяца правок небыло. Выполнение этих требований обязательно для прохождения Code Review. Не выполнение — достаточный, но не необходимый (есть еще ТЗ) аргумент для деклайна PR. ТЗ — требования необходимые для автоматизации конкретного бизнес-процесса, либо требования к ИС в целом. Невыполнение ТЗ — также деклайн. Если разработчик выполнил и требования и ТЗ — его код будет принят и оплачен, вне зависимости от его отношения к продукту.

Мы, собственно, говорим про одно и тоже, но оцениваем его по разному. Вы говорите что вас устраивает интерфейс ТЗ — бери и выполняй. Сделал — молодец, не сделал — п… ц. Я говорю, что разработчик, воспитанный на четком выполнении кем-то написанного ТЗ — это что-то вроде исполнительного солдата, чернорабочего, которому нельзя доверить что-то большое и ответственное, таск, который может содержать подводные камни и неожиданные ситуации.

Я согласен, что с аутсорсерами по другому нельзя, и именно поэтому среди них так много деревянных солдат Урфина Джюса. Лично мне с такими работать неинтересно, и более того, нанимать таких себе в компанию — стрелять себе в ногу. Мне не нужны исполнительные солдаты, мне нужны умные, инициативные и не боящиеся ошибок инженеры, которых прет от того, что они делают.
3 документа на 142 страницы А4

Было бы интересно с сим трудом ознакомиться :)

Сдается мне, автор и сам понимает что его отношение к работе (когда упор на написание кода, а не на продукт) неправильное, поэтому и озвучивает его с таким вызовом, типа «да, я такой, и не хочу меняться». Было время, у меня было такое же отношение. И я рад что я смог его изменить (пока еще не до конца, правда). Меня тоже не волновал конечный продукт, я тоже видел только код, я горел «правильным кодом». И в результате перегорел и полностью разочаровался в кодинге. Пришел к тому что кодинг не стОит того чтобы ставить его на пьедестал в своей жизни. Все эти языки и фреймворки стали казаться мне довольно ограниченными и просто скучными. Ум стал требовать новых челленджей, и написание кода его уже не могло удовлетворить. Все эти паттерны, командная разработка, аджайл — да не такое уж это и умное занятие на самом деле, на челлендж не тянет. А теперь я стараюсь думать в первую очередь про готовый продукт, что он даст юзерам. А код — просто средство, инструмент. И при таком подходе ко мне опять вернулось удовольствие от кодинга. Ведь я больше не отношусь к нему серьезно.
После работы в аутсорсе, заработал субъективное отторжение к нему на всю жизнь (даже был близок к тому, чтобы получить отторжение ко всему программированию). После долгого размышления пришёл к выводу: самое ужасное для меня в аутсорсе это то, что моя работа не имеет значения.

Поясню: в аутсорс-компании центром прибыли являются менеджеры (PM, аккаунты, по продажам и т.д.), именно они приносят компании деньги. А технические специалисты являются центром издержек. Да, без них никак нельзя, ведь надо кого-то продавать заказчикам. Но, в целом, они находятся на вторых ролях. В итоге все решения принимаются менеджерами среднего и младшего звена. Зачастую даже технические, зачастую вопреки опытным разработчикам в статусе лидов.
Несколько примеров из моей практики:
Тесты. TDD не было никогда. Как бы разработчики не настаивали. В половине проектов удавалось продавить интеграционные тесты, но при первом же цейтноте менеджеры их отменяли. Пишешь код, который нельзя показать заказчику — валяешь дурака.
Работа с системой контроля версий. Почему мы не можем показать фичу заказчику, когда её код уже написан? Что значит не можете смержить, потому что ждёте какой-то там кодревью? На лицо явный саботаж. Делайте merge немедленно!
— Самый показательный случай: менеджер попросил срочно поменять реализацию, поскольку в последний день спринта выяснилось, что у заказчика другое видение. Я предложил по быстрому заговнокодить (да, знаю, сам виноват), но с условием, что нужно будет выделить время, чтобы сделать нормально в следующем спринте. Конечно, в следующем спринте мне отказали с аргументом: «На тестовом всё и так работает, а что будет на проде нам совершенно неважно, потому что они будут выливать на прод уже после того, как мы закончим с ними сотрудничество.»

На всё это можно возразить: чувак, а какая тебе разница? Ты работаешь, получаешь за это деньги. Расслабься и получай удовольствие. Но даже если для кого-то это и недостаточно неприятный опыт, то есть пару следствий из такого положения дел.
Во-первых, профессионализм ничего не значит. Более того, он вреден. Лучше писать быстро, а не долго. В итоге имеем, что профессионал, с желанием написать действительно работающий и способный к расширению (для добавления новых фич) код, будет критиковаться. А быстро шлепающий говнокодер нахваливаться. Естественно, расти как профессионал в таких условиях как минимум трудно.
Во-вторых, место профессионализма займёт другое качество. В моём случае это была лояльность. Хорошим был сотрудник, который готов работать на выходных и всем доволен. А тот, который на ретроспективах говорит о проблемах был плохим. Потому что «мы команда, а в команде важно мыслить позитивно.»

P. S. Конечно это мой сугубо личный опыт. Возможно, что есть аутсорс компании, в которых этого нет. Возможно, в продуктовых это тоже присутствует. Но, как мне кажется, продуктовые компании больше смотрят на качество сервиса, которые они предоставляют. Потому что от этого напрямую зависит их прибыль. А, следовательно, приходит понимание ценности экспертизы технических работников.
Мысли хорошие, но никак не могу согласиться с последними двумя абзацами.

Профессионализм не может ничего не значить, так как в процессе принятия решений он является ключевым фактором. Если при обсуждении проекта условный разработчик не может описать менеджеру проблемы, которые могут возникнуть, предложить определенные решения и рассказать о плюсах и минусах данных решений, зачем вообще нужен такой разработчик?

И обратное верно — чем лучше развиты экспертные навыки, тем лучше менеджер сможет донести эти моменты до заказчика, а компания, соответственно, получить больше выгоды.
Так что профессионализм в «аутсорсовой» разработке очень даже много значит, не говоря уже о зарплате, уровне ответственности и т.д.

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

По поводу «лучше писать быстро, чем долго» — мне кажется вне зависимости от типа компании, надо быть просто работать эффективно, и не в контексте «эффективных менеджеров», а просто грамотно распределять время на задачи. ИМХО, но я повидал много людей, которые растягивают какие-то простые задачи на недели, а сложные пытаются решить за пару дней, нарушая при этом всевозможные сроки с дедлайнами. Опять же, профессионализм и здесь играет роль.

А если компании действительно абсолютно параллельно на то, как работает человек, я бы задумался над тем, чтобы сменить место работы, ведь никто никого не заставляет)
Под профессионализмом я имел в виду навыки написания систем, которые а) способны работать в боевых условиях, б) созданы с учетом добавлений/изменений. Да, каждый может подразумевать под этим словом разные вещи, тем более бизнес.

Как раз дело в том, что бизнес возлагает принятие решений исключительно на менеджмент. Разработчики в принятии решений не участвуют вовсе. Вплоть до технических, про которые я и упоминал. Канал «разработчик» <-> «бизнес» не налажен, объяснить ему про потерю денег не получится (не говоря о том, что бизнес не считает, что разработчик в этом разбирается). Возможность потерять клиента в мифическом будущем не интересует бизнес, потому что через год это через год. А если мы сейчас скажем клиенту, что нам надо, к примеру, не месяц, а два, зато будет качественно, то клиент уйдёт к тому, кто готов сделать за месяц. И мы потеряем клиента прямо сейчас. Что там говорить, если менеджера зачастую не интересует, что будет на следующей неделе, главное выбить показатели текущей.

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

Да, по поводу ухода из такой компании я абсолютно согласен (да и вообще по поводу любого ухода). Я даже не хочу сказать, что такая бизнес-модель плохая, так делать нельзя и фу-фу-фу. Если бизнес зарабатывает деньги таким образом и процветает, то флаг им в руки. Опять же, возможно это мой личный негативный опыт. Но я не вижу причин, по которым в аутсорс-компании бизнес бы заботился о том: как код написан, насколько там современная версия, сколько мы времени сэкономим в будущем, если сейчас потратим больше времени на изучение чего-то нового и т.д. Чтобы бизнес задавал вопросы разработчику по его экспертизе. Главное это получить деньги с заказчика здесь и сейчас. С этим справляются менеджмент, а разработчики с желанием высказать своё мнение о том, что неплохо было бы написать то, что будет работать и через год; или желанием потратить больше времени сейчас, чтобы сэкономить через пару месяцев, идут лесом. И я вижу предпосылки к тому, что об этом как раз будут заботиться в продуктовых компаниях. И у разработчика будет больше ответственности. И больше смысла ходить в офис.
В таком ключе полностью согласен с Вами.)
UFO just landed and posted this here
Есть подозрение, что ваш продукт покупали не потому что, он хороший, а потому что его умели продавать большим заказчикам, вероятно окологосударственным. Либо он был новый и быстрорастущий на своем рынке. Я уверен, что рано или поздно его придется переписать.
Вот, не так давно была история про переписывания — habr.com/ru/post/441456.
UFO just landed and posted this here
И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.

Врач такой приходит на работу и говорит: Я конечно понимаю что вы, уважаемый пациент, хотите жить. Но тут есть новая методика, которую очень хочется опробовать. Вероятность смерти — на 80% выше, но зато если выживите — будете бегать на 10% быстрее и лечить мне вас потом будет проще и интереснее. А теперь считайте от 10 до 0…
До откуда вы такие аналогии берете? С чего вдруг вероятность смерти 80%? Новые препараты более-менее регулярно появляются и их, так же как и ПО, тестируют перед тем как в реальный мир пускать. И я уверен, что в процессе тестирования множество препаратов показывают неудовлетворительные результаты и в проде их не используют. Чем это отличается от переписывание софта на новый лад? И внезапно, если этого не делать, то возможно пациент(бизнес) умрет(Нокия например), особенно если он изначально построен на IT составляющей, потому что придут конкуренты с новой технологией, которая «быстрее/выше/сильнее».
UFO just landed and posted this here
Вопрос власти, на самом деле. Если у технарей и ответственных за качество есть контроль, то долг управляем, будет и рефакторинг, и тесты, и развертывание с интеграцией. Если же все в руках продукт-менеджеров или, что еще хуже, продавцов, то пиши пропало, корову будут доить досуха.
UFO just landed and posted this here
Я один заметил единственный и вроде нерелевантный тэг к статье F#?
Это такая пасхалочка для внимательных?
Квест? ,-)
А разве можно опубликовать статью без единого хаба? Скорее всего, поставлен был от безысходности (автора не оправдываю)

Хочу посмотреть на проблему с другой стороны "экрана". То есть со стороны человека, который заказывает музыку.
Для начала, давайте определимся с терминологией. Аутстаф — сотрудник, работающий в другой компании, но предоставленный мне для реализации моих задач. Проходит техническое собеседование для оценки профессиональных навыков. Подчиняется внутреннему распорядку моей компании, делает то, что я скажу, в рамках должностных обязанностей и инструкций. Плачу я за его жопочасы. Аутсорс — сотрудник сторонней компании, которого я в жизни могу ни разу не увидеть. Мне вообще пофигу кто он, где и как работает, сколько получает. Деньги я плачу его работодателю за результат его работы. Сотрудник — сотрудник, который работает в моей компании, ну тут вроде как все понятно.


Моя первоочередная задача — получить от сотрудничества максимальную выгоду.


Если мы говорим об аутстафе — мне выгодно чтобы он писал. Мне не выгодно, чтобы он отвлекался на вникание в продукт. Мне нужно получить от него максимум полезного кода за минимальный промежуток времени. Для этого он получает требования, следование которым делают код полезным, а оценку полезности прозрачной и объективной. Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования. Он сдает код на ревью ровно так же как и мои штатные сотрудники, по результатам которого оценивается соответствие кода ТЗ и тем самым требованиям. Выполнил — молодец. Вот тебе следующее ТЗ. Нет — переделать. Снова не справился — прошу его работодателя прислать нового. Все строго по джире, все строго по часам. Я не хочу платить деньги за образование таких сотрудников. Я не хочу платить деньги за их кофебрейки, разглядывание котиков в интернетиках и их присутствие на митапах, где они абсолютно не нужны (ну понятно, все в разумных пределах, я не надсмотрщик над рабами). Я не хочу платить за вникание. Только бизнес, только код, ничего личного.


Если мы говорим об аутсорсе — все сильно проще. Есть то же самое ТЗ. Как правило, чуть более сжатое, поскольку описывает не одну задачу на несколько часиков, а требования к значительной части продукта, либо к продукту в целом. Да, я закладываю время на обсуждения и уточнения этого ТЗ с второй стороной. Я закладываю в бюждет чуть больше чем изначально в договоре (НИКОГДА в моей практике, финальная стоимость не была равна стоимости по договору). Я отдаю ровно те же самые требования, которые получил аутстафер. Я получаю результат. Я оцениваю результат. Я плачу за результат, если он меня устроил. Все. Больше меня ничего не интересует. В продукт должен вникнуть менеджер, с которым я работаю. Или не должен понимать продукт, но должен правильно понимать ТЗ. Будут ли вникать в него программисты той фирмы — мне не важно.


Мой сотрудник: должен знать все те требования к коду наизусть. Еще лучше — интуитивно понимать их. Должен понимать архитектуру, ожидания от продукта и его философию. Должен, потому что у меня просто не хватит времени писать для всех них подробные ТЗ как для аутстаферов. Должен учиться, развиваться, думать. И я готов за это платить, мне это выгодно, поскольку такие сотрудники экономят и мое время, и бюджеты компании, и вообще — главная ценность софтверной фирмы.


Так что все, что описано автором — вполне себе так и должно быть. И не приплетайте сюда говнокод и рассуждения, кто лучше пишет. Это ровным счетом никак не зависит от того, в какой компании работает человек. Это зависит исключительно от его личных качеств и навыков, а также от умения читать требования заказчика, как внутреннего, так и внешнего, и выполнять их. Если заказчик таких требований не предоставил — его проблемы.


И да, фреймворки и кододрочерство тоже к этой проблеме не имеют никакого отношения. Все должно быть строго регламентировано в рамках ТЗ. Аутсорс или аутстаф, меняющие по желанию стек продукта — нонсенс или идиотизм заказчика.

Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования.

Все должно быть строго регламентировано в рамках ТЗ.

Должно-то оно должно, но проблема в том, что в крупных проектах таких ТЗ не существует (я искренне хотел бы в это верить, но факт есть факт — их нет). При интеграциях, при пересечениях логики — на каждом шажке в крупных проектах есть куча нюансов и подводных камней. В своей практике часто вижу как разработчик-пофигист делает все строго по ТЗ, а шаг влево шаг вправо и упало. И ведь с такими и спорить невозможно — они никогда ни в чем не виноваты. Мозговой центр разработки — это разработчик, а не менеджер. И качество делают разработчики. А «максимум полезного кода за минимальный промежуток времени» на практике почти всегда с течением времени приводит к большим затратам бюджета, нежели экономии здесь и сейчас

Простите, я не знаю как в крупных проектах, я знаю как у меня (на текущий момент — банковская группа). Если те проекты не умеют работать с аутсорсом и аутстафом — пусть не работают. Я — умею. Такой вывод делаю на основании того, что получаю от этого вполне ощутимую прибыль. Именно потому что ТРЕБУЮ делать строго по ТЗ. Если ТЗ написано криво — это только моя ответственность. Если оно написано криво — я получу за те же деньги кучу БЕСПОЛЕЗНОГО кода. Полезный код — это код который легко поддерживается, рефакторится, переиспользуется, автоматизирует бизнес-процессы. Это те требования, которые я к нему предъявляю (точнее результат тех требований). С чего бы он должен приводить к большИм затратам, ну или как минимум, к затратам бОльшим чем код, написанный за большое количество времени? Как тут время вообще коррелируется с качеством? Вы искренне считаете, что "Hello, world!" на который потратили 2 недели будет сильно качественнее чем тот, который смогли написать за 2 минуты? А вам не приходит в голову, что разработчику из вашего примера ТЗ и было написано потому что шаг влево/вправо — и все упадет? Нахрен мне его самодеятельность не нужна в этом случае, я не хочу чтобы что-то падало. От этого страдает бизнес.

Простите, возможно не до конца проникся Вашему трактованию о «полезном коде». Если так, то да. А что касается времени и качества, то услышьте меня, не надо входить в крайности про «Hello, world!». Зачастую менеджеры в основном далеки от разработки. Они видят потребность бизнеса и стремятся во что бы то ни стало реализовать ее максимально быстро, полагая, что внутренняя архитектура проекта — пустая трата времени. И это именно то, с чем я имею дело. И вот этот вот и приводит к обратному Вами трактованию полезного кода и всем прилагающим. У меня есть собственные примеры командной работы, когда из-за таких гонок, итоговый проект выходил на несколько месяцев позже срока. И подобный ущерб очень существенен, он перекрывает все — потеря прибыли за пол года, разработка длилась больше на пол года. В ТЗ же упор обычно делается именно на новую функциональность, и на моей практике, как я уже сказал, в нем никогда не просчитываются все нюансы текущей функциональности, которая развивалась и менялась годами. Не знаю степень сложности Ваших систем, но с тем с чем работаю я — определить все нюансы невозможно до начала ее реализации функциональности. Хоть и ТЗ смотрят несколько человек, перед реализацией. Вот тут и встает вопрос о степени вовлеченности разработчика в процесс и его мотивации — собственно это играет основополагающую роль. Итого — «гонки» менеджеров и пофигизм разработчиков ведут к колоссальным затратам. Возможно наша команда не умеет работать, а Вы умеете, но мы имеем то что имеем. И примеров у меня, к сожалению, много

Если менеджер не умеет слышать разработку — это действительно очень печально. Отсутствие архитектуры — еще более печально. Тут я Вас прекрасно понимаю, поскольку у самого вполне себе программерский бэкграунд, и через все это неоднократно проходил. Но разговор изначально не о том. В моем случае ТЗ пишу я САМ. А не менеджер компании аутсорсера ДЛЯ МЕНЯ. Я знаю, на сколько все мои системы и модули завернуты в абстракции, где какие имеют коннекторы и так далее. Я знаю архитектуру, а не менеджер. Именно поэтому, мое ТЗ не оставляет шансов менеджеру-аутсорсеру всунуть мне какашку, которую вы описываете, и которая у меня просто не будет работать, а если и будет — за дополнительные деньги. Я ее просто не приму, не заплачу за нее, и даже не буду париться, выслушивая какой я нехороший, поскольку они вот старались, сроки соблюдали и так далее…

В моем случае ТЗ пишу я САМ.

Если ТЗ учитывает особенности реализации проекта, то его очень тяжело написать. У вас много времени отнимает детализация?

Слишком. В последнее время трачу на ТЗ и прочую документацию (за исключением пользовательских мануалов, ими занимаются отдельные люди) до 6 часов в день. В основном, это формализация требований бизнеса (перевод с русского на программерский). Для работы с аутстаферами удалось выделить отдельного человека, иначе вообще кроме бумажек ничего бы не видел. Оставшиеся 2 часа — либо ревью кода, либо живое общение с бизнесом/исполнителями. Кодить времени почти уже нет.


UPD: работа с таск- и баг-трекерами в это время тоже входит.

UFO just landed and posted this here

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


С уважением, директор департамента развития банковских технологий, ПАО "............"

Ну, если судить по премиям и зарплатам, мы все тут молодцы будем)

Не по премиям и зарплатам, а по KPI. Да, это общая оценка, но вот принципы, на которых она строится — вполне конкретны. И показатели вполне объективны (в моем случае, это на 80% RoA, CuS, ClS). Если знаете другой способ оценить эффективность — пишите статью, с удовольствием ее прочитаю, и обещаю хорошо подумать (без какого-либо сарказма). Я, к сожалению, таких способов не знаю.

UFO just landed and posted this here
Быть или не быть?
Что благородней: стать расходником-тонером в принтере, печатающей для Хозяина Деньги, тонером, который меняют каждые три месяца, и которому все равно что и на чем печатать, или стать принтером, печатающим для того же Хозяина те же Деньги?
Принтер меняют гораздо реже, а кроме того, у принтера есть свои собственные предпочтения по размеру и качеству бумаги и прочие интересные особенности.
Стать Хозяином ни в статье, ни в комментах — не обсуждается.
в этой статье заметил разницу только между разработчиками и разработчиками словоблудами пока только. вода водой
Однажды мы с командой проводили тех-интервью, кандидат неплохо шарил, но мы решили, что он нам не подходит только потому, что пришел из продуктовой компании.

Эпизод V: Гребец наносит ответный удар.

Возможно, этому виной плохие примеры. Одна продуктовая фирма, где я работал, использовала C# 2.0. ДВА НОЛЬ. Аргументировали они просто: проект большой, если переносить его на новую версию, наплодим кучу багов. И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.

Я в таких случаях наоборот, не понимаю бизнес. Консервативных разработчиков очень легко понять, так как эта платформа, которую они знаю и им проще с ней работать. А бизнес, который игнорирует потенциальные проблемы в духе "у вас тут уязвимости, которые никто не закроет, так как продукт не поддерживается" и потенциальное удорожание рабочей силы мне очень сложно понять.

и потенциальное удорожание рабочей силы


Ну какое удорожание, о чем Вы? Саппортер как раз всегда стоит дешевле, чем нормальный разработчик, испытывал это на своей шкуре не раз. Ни разу не видел вакансий, где саппортеру платили бы хотя бы в 2 раза выше, чем нормальному девелоперу, занимающемуся только свежими проектами, а не копролитами мамонта.
Sign up to leave a comment.

Articles