Бизнес и продажа фичей важнее качества кодовой базы?

Question

[krakaka]

Речь идет о web разработке. Все встречающиеся мне компании больше уделяют времени менеджменту и продажам, росту пользователей, чем кодовой базе. Все встречающиеся мне проекты имели плохую кодовую базу, я имел дело с СНГ и зарубежными проектами. Большие бизнес приложения выполнены по большей части в процедурном стиле конструкциями if-else, усеянными бесчисленными комментариями с ссылками на задачи. Отсюда вытекает большое число негативных последствий, которые и подрывают этот самый бизнес пропорционально движению по графику технического долга в сторону застоя.

Comments

[Akina]

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

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

[krakaka]

Akina, я не управленец, но возможно в менеджменте есть какие-то практики ведения продукта с учетом именно технической стороны?

[Валентин]

krakaka, конечно есть. Придёт новый технический директор со словами «я оптимизирую затраты на внедрение фичи на 30%», тогда да, будет и кодовая база, и рефакторинг, и оптимизация штатной структуры.

[Константин Нагибович]

Валентин, не факт. Когда для этого ему потребуется N ресурсов (деньги, время и т.п.), то бизнес ему скажет - работает, не трогай.

[Валентин]

Константин Нагибович, опытный руководитель всегда найдёт как перераспределить ресурс.

[Vitsliputsli]

Akina,

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

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

krakaka,

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

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

[krakaka]

Vitsliputsli, кажется Вы не прочитали вопрос )

[Vitsliputsli]

krakaka, или возможно Вы не прочитали ответ.

Получился очень "полезный" диалог.

Answer 1

[Рональд Макдональд]

Лол. Поздравляю с прозрением. Программист (админ, юрист, whatever) - это всего лишь специально обученная мартышка, а заправляет всем менеджмент. Так было, так есть, и так будет, и топу вообще плевать, что процедурные конструкции оскорбляют нежные чувства какого-то челика, который сегодня тут, а завтра уже нет.

P. S. На всякий случай отвечу отдельно - ответ на вопрос из заголовка: "Да".

Comments

[krakaka]

а также топу плевать, что внедрение средней фичи занимает месяц и более, и что после ее внедрения полгода будет тянуться вереница багов? или что приходится поддерживать 3 и более релизов одновременно? и что происходит постоянная смена приоритетов в разработке?

[Рональд Макдональд]

krakaka, да. Глубоко. Топу не будет плевать тогда и только тогда, когда из-за бага вдруг встанут бизнес-процессы и фирма начнёт терять деньги.

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

[krakaka]

Рональд Макдональд, спасибо

[Василий Банников]

krakaka,

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

1. Если такие долгое внедрение фич укладывается в бюджет и баги не ломают бизнес - никто не обратит внимание.
2. А сколько займёт рефакторинг?
3. А на сколько сильно улучшится ситуация после рефакторинга?
4. А не станет ли ещё хуже после рефакторинга?
В топах тоже не идиоты сидят (обычно). Если до состояния легаси проект смог дожить, то значит с бизнесом всё не так уж и плохо, и менеджмент справляется со своей работой.

[Vitsliputsli]

Рональд Макдональд, топ-менджмент не решает вопросы рефакторинга. Как вы себе представляете, сидит коммерческий директор и рассуждает о процедурном подходе и ООП в коде? Ну если только в компании из 2 человек. Разработчики (речь про тимлидов и архитекторов), как и любое другое подразделение, должны уметь разговаривать с людьми и доказывать необходимость вещей, которые считают важными. А заявления "это не мы, это нас злой бизнес заставил" - детский сад. Бизнес не проревьют ваш код и не заявит, что все нужно переписать на говнокод, разработчик это делает сам, сознательно.
Менеджмент от бизнеса всем не заправляет, у него своя зона ответственности, у технарей своя. Сроки и доставка функционала - это ответственность и тех, и других. Другое дело, что менеджеры от бизнеса умеют добиваться своих целей, а технари нет и ноют, что их заставили.
В итоге, если разработчики компетентны, то у них нет оправдания "нас заставили". Если они также умеют разговаривать, то и с бизнесом находят общий язык. Другое дело, что компетентность техническая в IT очень низкая в большинстве случаев, тем более, если работадатель нанимает сотрудников за гроши. А не умеют разговаривать еще большее кол-во.

[Рональд Макдональд]

Vitsliputsli,

оп-менджмент не решает вопросы рефакторинга.

Ну уж извините, дальше не читал. Я такого не утверждал.

[Vitsliputsli]

Рональд Макдональд,

Ну уж извините, дальше не читал. Я такого не утверждал.

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

[Рональд Макдональд]

Vitsliputsli, ну вот последнее ваше сообщение прочитал. А первое не стал читать, потому что вы приписали мне слова, которые я не говорил, а потом, очевидно, стали их опровергать. Вот и всё.

[Vitsliputsli]

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

[Рональд Макдональд]

Vitsliputsli, хорошо.

Answer 2

[Василий Банников]

Бизнес и продажа фичей важнее качества кодовой базы?

На ранних этапах - точно да, тк написание идеального кода занимает заметно больше времени, чем написание минимально работающего кода.
+ Разработчики, которые умеют писать качественный код часто стоят дороже.
Таким образом пока разработка идёт, а фичей нет - бизнес не получает прибыль, но при этом тратит много денег на разработку. Это прямой путь к банкротству.

А техдолг можно порешать позже, когда будет на это время.

Все встречающиеся мне проекты имели плохую кодовую базу,

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

Comments

[krakaka]

спасибо. но по вашему ответу выходит так, что и на ранних этапах, и на этапе легаси код всегда будет плохим

[Василий Банников]

krakaka, этап с легаси можно отсрочить, если контролировать техдолг.

[Алексей Ярков]

А техдолг можно порешать позже, когда будет на это время

Сейчас прям больно стало ))

[Василий Банников]

Алексей Ярков, по тому что на рефакторинг никогда времени нет?))))

[Василий Банников]

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

[Алексей Ярков]

Василий Банников, примерно так ))

[Алексей Ярков]

Василий Банников, а мы вроде как закладываем время при планировании, но всё равно копим долг потихоньку ))

[krakaka]

Василий Банников, еще нужно сказать что рефакторинг в полноценном смысле невозможен в запущенных случаях

[Василий Банников]

krakaka, возможен всегда, хотя иногда рефакторинг = снести и переписать

Answer 3

[mimocrocodil]

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

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

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