Pull to refresh

Comments 14

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

Вы немного забыли, что тут ситуация несимметричная: разработка в 90% компаний такой же обслуживающий персонал экономики предприятия, как уборщица или, там, токарь. Экономика и менеджмент могут сколько угодно не знать язык программистов и быть деспотами и самодурами, а на мороз без премий пойдет программист, а не наоборот
Ну это скорее советы насчет того, как правильно пытаться объяснить, что есть техдолг. Будем честны, далеко не все имеют даже минимальное представление о том, как происходит разработка ПО.
Очень важная статья на самом деле. Программисты для того, чтобы расти, нужно понимать и экономику и менеджмент, чтобы уметь правильно взаимодействовать.
Я думаю не нужно никого заставлять проникаться техническим долгом, тем более руководство.

Если руководитель это не директор ларька, то он и сам это должен понимать или иметь доверие к техническому директору, который и принимает решение.

А доказывать что-то некомпетентному руководителю это непродуктивно.
И я тоже не понимаю, зачем заставлять проникаться? Об этом можно разок подсказать. Не слушают — и черт с ними, т.к. это проблемы управления фирмы, есть отдельные ответственные за эту работу люди.
Для 99% программеров по найму лучшая стратегия — это раз в 2-3 года менять место работы с повышением в з/п. А вот решать какие-то проблемы бизнеса, о которых он не просил — это нарываться на обвинения, что вы вместо работы развлекаетесь. Рискованная стратегия и без видимых выгод.
Так, ладно, а зачем тогда вообще писать качественный код? Тогда можно писать любой код, за который не уволят, или который на заметят, или не заметят в эти 2-3 года.

И второй вопрос — какая мотивация работы у программиста?
Так, ладно, а зачем тогда вообще писать качественный код?

Это довольно скользкий термин. Думаю, даже в пределах одной фирмы понятие качественного кода будет расходиться.
С одной стороны есть минимальный уровень, который требует бизнес — он как правило чем-то описан.
С другой — есть личные предпочтения разработчика — его чувство прекрасного, желание показать себя перед коллегами, в том числе и будущими.
С максимальной стороны качественный код тоже обычно ограничен бизнесом, т.к. он не очень то хочет тратить на него деньги. А «качественный код» — это обычно «потратим больше времени сейчас, чтобы меньше тратить потом».
— Очень круто, когда все эти 3 находятся в одной точке. Я думаю, что чаще всего «писать качественный код» — это о личных предпочтениях разработчика. Отсюда и такие проблемы при объяснении бизнесу.
Тогда можно писать любой код, за который не уволят, или который на заметят, или не заметят в эти 2-3 года.

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

Пффф… А можно построить digital factory и колбасить без тех.долга. Слабо?
Но! Стоит разделять тех.долг и рефакторинг архитектурных\технических решений в случае изменения требований.

«Руководство не даёт мне заняться рефакторингом legacy-кода!»

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

И даже когда пытаешься им объяснять, какие преимущества даёт опрятный код

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

За рефакторинг никто платить не будет. Положение выглядит безнадёжным.

Как на счёт такой стратегии?:
Не говорить руководству про технический долг и рефакторинг… чтоб они даже слов таких не знали.

Просто каждый раз при оценке абсолютно любой(!) задачи закладывать в озвученные сроки ещё ~200% времени. Т.е. когда просят добавить кнопочку — не бить себя в грудь и говорить что это плёвое дело на пару часов. А с покер-фейсом говорить что эта кнопочка займёт два дня (даже если там работы на пару часов).

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

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

P.S. заметил что некоторые разрабы сами склонны занижать сроки, особенно публично… типа та что там делать… делов на пять минут. Толи повыпендриваться, толи страх показаться некомпетентными. Вместо того, чтобы наоборот нармально запаса заложить для подстраховки.
Sign up to leave a comment.