LINUX.ORG.RU
ФорумTalks

Бизнес-задачи, менеджмент, быдлокодинг

 , , , ,


1

2

(в изоляции скучно, не кидайте слишком большие камни)

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

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

Бизнес нанимает программиста решать свои задачи, платит ему хорошие деньги, программист их решает.

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

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

Из чего следуют вопросы:

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

Не ты один об этом.

1) Да, в первую очередь задачи бизнеса. Но если сумеешь обосновать свою позицию — сделаешь по своему.

2) Переквалификация в манагера, следствие успешности первого пункта.

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

4) Знавал я начальника, хозяина бизнеса, начинавшего с гребли веслом, прошедшего все ступени, сделавшего свой бизнес. И что? Да ничего — тупые девки манагерши, текучка кадров у прогеров и страшный говнокод в продукте. Почему? А я по чём знаю...

deep-purple ★★★★★ ()

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

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

micronekodesu ★★ ()
Ответ на: комментарий от beastie

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

WitcherGeralt ★★ ()

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

Korchevatel ★★★★ ()

Вот граница и с этой стороны - мы не геи.(с)

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

pon4ik ★★★★★ ()
Ответ на: комментарий от deep-purple

Начальник давно познал дзен, ему плевать, потому и начальник.

WitcherGeralt ★★ ()

Избегание крайностей

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

Camel ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Чтобы понять бизнес нужно самому стать бизнесом

А что делать, когда говнокод наберёт критическую массу? Увольняться?

Почувствуйте себя маленьким бизнесом, берите бюджет (время) и осваивайте.

Camel ★★★★★ ()
Ответ на: Избегание крайностей от Camel

Есть одна маленькая проблемка.

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

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

Если ты о последних — ты прав.

deep-purple ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

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

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

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

micronekodesu ★★ ()
Ответ на: комментарий от deep-purple

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

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

micronekodesu ★★ ()
Ответ на: комментарий от deep-purple

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

WitcherGeralt ★★ ()
  1. Бизнес в первую очередь. Если это бесконечная гонка, без рефакторингов, я бы подумал сваливать. Если бесконечная гонка, без рефакторингов, с постоянными срывами сроков и стрессами (как так? тут же на 15 минут работы), в первую очередь здоровье (пора валить).

  2. Или искать новое место работы. Мне пока нравится роль разработчика.

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

outtaspace ★★★ ()
Ответ на: комментарий от micronekodesu

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

У нас, зачастую, архитектор — это тот, у кого борода длиннее. А на полномочиях это не сильно отражается

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

deep-purple ★★★★★ ()

решать в первую очередь задачи бизнеса

Разумеется. Ты профессионал, или где?

и делать технически безупречный продукт

Откуда вообще взялась идея, что есть какое-то «И»? Это твои личные амбиции. Ты конечно вправе их попытаться реализовать, но платят тебе не за это.

переквалифицироваться в менеджера

Ну, если тебе так хочется. Только не надо себя обманывать, что ты д’Артаньян. Ты бабуин и хочешь в иерархии других бабуинов занять позицию повыше, вот и всё.

должно ли вообще кого-то волновать качество

Нет, конечно. Если все довольны соотношением цена/качество, то и говорить не о чем.

no-such-file ★★★★★ ()
Ответ на: комментарий от micronekodesu

убивать недели на прорабатывание архитектуры

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

deep-purple ★★★★★ ()

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

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

goingUp ★★★★★ ()

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

Reset ★★★★★ ()

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

xaizek ★★★★★ ()
Ответ на: комментарий от deep-purple

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

Работодатель прав. Если выбрать «недели на прорабатывание архитектуры», то получится как в этом видео https://youtu.be/DwAIai5ZfOE

Reset ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

не будешь справляться с тем, за что тебе формально платят

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

При этом если моя работа оценивается по количеству закрытых тикетов или еще какому сорту KPI - мне вообще все равно что там и как работает, каждый мой тикет решает описанную проблему, тесты проходят, какие претензии?!

micronekodesu ★★ ()
Ответ на: комментарий от deep-purple

А у нас каждый (из сильных) лезет со своим видением, дебаты, ор, ругань, примирение.

Это решается просто. Должно быть только одно видение – то как проект видит начальник, остальные со «своими видениями» должны идти лесом.

Reset ★★★★★ ()
Ответ на: комментарий от deep-purple

Ну не скажите. Возьмем игровую индустрию, сколько раз переносили анонсированный выход культовых игорь на очень большой срок? Дофига. И даже когда предзаказы уже шли тоже переносили. И ничего. Разумно. Звиняйте не успели.
Вам что бы зерлинг случайно с орком столкнулся или как? :)
Или тот же mac os x при Джобсе? Так же переносили. А что произошло после смерти Джобса? Начали выпускать точно по срокам, но версии забагованные дальше некуда. Этому посвящено много тем, что программеров гонят сроками. А они гонят говнокод.
На днях столкнулся с аутглюк 365(2019), ребята это полный пипец. Как можно было сломать то что работало в предыдущих версиях я хз. Точнее не сломали, но требует не очевидного для пользователя. Ранее(предыдущие версии) жмяк, жмяк, жмяк, готово. Пояснение, в случае imap и выдачи дефолтоной структуры в виде inbox/folders* inbox не загружает письма. Надо же, теперь надо найти ещё настройки и в них указать что рут фолдер inbox. Догадался опытным путем. Теперь вопрос знатокам: Почему в предыдущих версиях это не надо было делать?

anc ★★★★★ ()
Ответ на: комментарий от xaizek

Хотел написать нечто подобное. Опередили. Полностью поддерживаю! write only код долго не проживет.

anc ★★★★★ ()

цель любого бизнеса — максимизация прибыли

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

buddhist ★★★★★ ()
Ответ на: комментарий от deep-purple

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

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

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

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

WitcherGeralt ★★ ()
Ответ на: комментарий от no-such-file

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

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от xaizek

Дихотомия есть, т.к. бизнес и инженеры говорят на разных языках, а между ними либо клоуны, либо и вовсе никого.

WitcherGeralt ★★ ()

Работник должен решать поставленые задачи. Если ты думаешь, что задача поставлена неправильно, ты это аргументировано объяснил начальству, но оно с тобой не согласно, то тут 2 варианта:

  1. Ты прав. Тогда тебе стоит поискать работу в другом месте, да ещё и с повышением.

  2. Ты не прав. Работу поискать всё ещё стоит, но скорее всего ты ничего намного лучше не найдешь.

Вариант 2 случается в бОльшем количестве случаев, потому что ты самый умный, очевидно.

То же и с кодом. Он должен решать задачи, а не просто «быть красивым». Если тебе важен каждый микроампер-секунда или каждая микросекунда – да, стоит потратить время и усилия для того, чтобы оптимизировать код. Если у тебя планируется проект на 3487567845706 строк, то да, стоит продумать архитектуру. Но принимать это решение должен квалифицированный начальник кодера.

tyakos ★★★ ()
Ответ на: комментарий от Reset

Работодатель прав. Если выбрать «недели на прорабатывание архитектуры», то получится как в этом видео https://youtu.be/DwAIai5ZfOE

Видосик порадовал. Но вы похоже так и не поняли основной мысли в нем. «прорабатывание архитектуры» нужно в любом случае. Другой вопрос кем и как.
Знаете откуда возникают эти «отчеты на сотни страниц» ? Есть генераторы в которые вы забиваете базовые параметры, жмем готово и в результате получаете огромный документ который предоставляется заказчику. Заказчик доволен, такой талмуд, заплатим. Мало кто их читает. Я как-то подобный из двух томов страниц A4 по 150 каждый осилил. Это было про нашу инфраструктуру. Такая херня.... Там правды близко не лежало. Но «свои семь я уже съел» (с) чебурашка.
В этом плане из аналитиков E&Y не гонят пургу. Но у них и расценки соответствующие. БОльшая же часть «аналитиков» довольствуется готовыми генераторами.

anc ★★★★★ ()
Ответ на: комментарий от tyakos

У меня №3, что я прав согласны. Но якобы только кошки быстро плодятся, а пока нужно работать как есть. Со временем обязательно скален!

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)

Должен ли инженер разработчик решать в первую очередь задачи бизнеса

хватит тащить ререйта хабра сюда

darkenshvein ★★★★★ ()

Итак, ни для кого не секрет, что цель любого бизнеса — максимизация прибыли.

Нет! Цель любого бизнеса - увеличение стоимости компании.

anto215 ★★ ()
Ответ на: комментарий от WitcherGeralt

У меня №3, что я прав согласны.

Ну если вы это не делаете, то наверно недостаточно экономически выгодно. Ну или денег совсем нет на пару месяцев зарплаты.

А вообще пиши и согласовывай план развития «на перспективу».

tyakos ★★★ ()

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

Что-то не припомню, что бы Геральт из Ривии грузился по таким пустякам.

Бизнес нанимает программиста решать свои задачи, платит ему хорошие деньги, программист их решает.

все вокруг козлы, а разработчик Д’Артаньян, и все вопросы всё равно решаются через него

Когда говнокод крутится, а бабло мутится, должно ли вообще кого-то волновать качество?

А вот это уже ближе к правде, хехе.

чеканной монетой, чеканной монетой…

BOSS-NIGGER ()
Ответ на: комментарий от tyakos

недостаточно экономически выгодно

Даже если так, проекты без этих мер — мёртвый груз. Либо пилить нормально, либо отказываться.

Отрицание, гнев, торг ← мы где-то здесь, депрессия, принятие.

А вообще пиши и согласовывай план развития «на перспективу»

Я разработчик, надо оно мне?

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

Тогда расслабься, получай удовольствие и присматривай новое место.

tyakos ★★★ ()

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

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

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

Должен ли инженер разработчик решать в первую очередь задачи бизнеса

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

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

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

n_play ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)