Comments 314
Тогда уж так «все должны решать проблемы бизнеса». Рабочий на заводе тоже решает проблемы бизнеса.
Ну, в каком-то смысле, это именно так.
(особенно если вместо "бизнеса" поставить "потребителя")
и да, бизнес это не всегда про «продать» товар, это вполне может быть и благотворительность или какой нибудь исследовательский. тогда и цели/проблемы другие.
начала 20 века. Он полировал внутреннюю поверхность какого-то прибора которая не влияла на работу прибора и не была видна потребителю. Когда его спросили зачем он это делает, полировка ведь не будет видна. Он ответил, что бог-то видит.
Мотивы как работников так и потребителей, которые в другой ипостаси работники, в какой-то мере иррациональны. Наука о человеке не точная наука вообще ни разу.
Сеньоры и миддлы, решая проблемы бизнеса, создают проблемы которых до решения проблемы у них не было. В долгосрочной перспективе игра с нулевой суммой. Все умрут, солнце погаснет. У потребителя и у работника должны быть какие-то общие долгосрочные цели, что-бы игра для них была вин-вин.
У потребителя и у работника должны быть какие-то общие долгосрочные цели
Какие у меня долгосрочные общие цели с неизвестной мне компанией в Новой Зеландии, которая кому-то продает молоко, пользуясь продуктом, в разработке которого я участвую?
Если деньги вам идут непосредственно от новозеландской конторы — пожалуй, да, общие цели у вас есть.
Кто платит деньги за продукт — тот и потребитель.
Кому платит?
Если деньги вам идут непосредственно от новозеландской конторы — пожалуй, да, общие цели у вас есть.
Какие же?
Кому платит?
Ваша зарплата из каких средств формируется?
Какие же?
У вас — продолжать получать деньги. У них — продолжать делать свою работу с помощью вашего продукта. Но это не точно.
Ваша зарплата из каких средств формируется?
Оу, это длинная цепочка. Новозеландская контора платит не мне, и даже не моему работодателю.
У вас — продолжать получать деньги. У них — продолжать делать свою работу с помощью вашего продукта.
Так это же две разные цели, а не "общая цель".
это длинная цепочка. Новозеландская контора платит не мне, и даже не моему работодателю
Человечество придумало много разных вариантов товарно-денежных отношений, не все можно описать одной фразой ;)
Так это же две разные цели, а не «общая цель».
Ну нет и ладно ;) Можно сказать, что общая цель — продолжать заниматься тем же. Стабильность, наше всё. В древнем Риме у патрициев и рабов были общие цели? Но Рим просуществовал дольше, чем любая экономическая теория.
Человечество придумало много разных вариантов товарно-денежных отношений
Тогда непонятно, зачем уточнение "если деньги вам идут непосредственно от новозеландской конторы".
Можно сказать, что общая цель — продолжать заниматься тем же.
Неа, она не общая, она раздельная.
Иначе заявление "У потребителя и у работника должны быть какие-то общие долгосрочные цели" выше теряет всякий смысл.
Вообще, интересно, вы своим вопросом «подсветили», что мне лично мало нравится слово «цель», и почему это так (термин «долгосрочная цель» напоминает оксюморон).
Представляете себе, был как-то завод у мало известного господина Форда, так вот на этом заводе, любой мог подойти к нему, и предложить идею о том как и что можно изменить и улучшить, и если идея была хорошей и приживалась, то за это можно было получить и бонусы, и повышения. Так к чему это я, эти рабочие получается тоже думали как решить проблемы бизнеса?
Если рассматривать сферического коня в вакууме — да согласен. А в жизни совсем не так. В энтерпрайзе вообще печаль. Там часто случаются разорванные коммуникации и никто не может сказать какую бизнес задачу решает программист. Есть варианты когда программисты используются для решения карьерных вопросов (посидеть начальника, скинуть неугодных). Есть программисты которые по 15 лет получают зарплату а результата из работы никто не видел.
Поэтому вменение что программист что-то должен бизнесу кроме оговореного в трудовом договоре я считаю натяжкой и натяжкой вредной.
Да, к сожалению так бывает и это не редкость. Поэтому я написал "На уровне своих компетенций, должности и опыта". У меня например в компании разорванные коммуникации. И в договоре прописано что я должен учавствовать и решать проблемы бизнеса (размыто как всегда, но пунтик есть), но даже без этой приписки, моего опыта хватает понимать какую проблему решит конкретно эта задача. Даже если задача изначальна абсурдна (что тоже к сожалению бывает). 15 лет получает зарплату, а результата не кто не видит — тоже относиться к компетенциям, опыту и должности. Да и тут с большей долей вероятности, то что результата не видно, не значит что его нет. Он же за что то деньги получает.
Решать проблемы бизнеса — да. Решать задачи бизнеса — нет! Это неравнозначные понятия. Задачи бизнеса — это то что решается бизнес-планированием, продажами и всем этим. Проблемы — это как раз сфера деятельности ИТ — автоматизация, повышение эффективности некоторых процессов, снижение издержек в бизнес-процессах.
Muxto говорит о том, что менеджмент как раз успешно часто подменяет эти понятия, вынуждая делать программистов не их работу.
Apokalepsis же пишет о том, как оно должно быть.
Тут речь, скорее, о бизнес-задачах, а не о задачах бизнеса. Есть, например, проблема: много времени и денег тратится на обслуживание клиента в отделении банка. Бизнес-задача: уменьшить это время. Кто-то поговорил или даже посидел с операционистами, увидел, что, например, ФИО клиента вводится в пределах одной операции три раза и сформулировал техническую задачу по своему опыту работы с вордом: "сделать специальный буфер, из которого эти поля заполняются одной клавишей".
Да, это даже решит бизнес-задачу, но "настоящий сеньор" спросит "а какую бизнес-задачу решаем?" и узнав, что это уменьшение времени заполнения трёх форм, может предложить, например, одну форму для операции или одно заполнение ФИО на всю сессию работы с клиентом, если он хочет несколько операций совершить, а то и подтягивание ФИО из базы по предъявлению, например, карты этого банка или паспорта. А то и вообще предложит создать веб и/или мобильное приложение самообслуживания клиентов.
Пример не очень актуальный по нынешним временам, но лет дцать назад многие "бизнес-люди" и не знали о многих технических возможностях, просто им мысли в голову не приходили, что можно не заполнять три экранных формы, потому что регулятор требует три печатных формы, а заполнить одну экранную и сформировать три печатных, не говоря о том, чтобы вообще жить без экранных.
"Задача бизнеса" это из разряда "увеличить продажи за год на 100%" или "выйти за год на международный рынок, обеспечив за год не менее 20% доходов с него". "Бизнес-задача" — "обеспечить присутствие продающей площадки в англоязычном сегменте Интернета", которая трансформируется в техническую, например, "интернационализировать и локализовать под English US/UK русскоязычный сайт". И вот тут сеньор, получив техническую задачу, может спросить "а какую бизнес-задачу решаем?" и получив ответ "обеспечить присутствие продающей площадки в англоязычном сегменте Интернета" предложить, например, написать отдельную версию сайта с нуля. Или подрядить веб-студию, хорошо знакомую с целевыми рынками, а не пытаться самим выяснять культурные и правовые нюансы. или просто "давайте зарегаемся на и там продавать, а если пойдёт, то уже будем думать дальше"
и до сих пор в выпадающем списке, позиции заполняются отдельными запросами, в один поток, а поиск работает посимвольно — если смотреть как операторша ждёт между вводом данных.
И да всё же слово «должен» не имеет смысла за пределами контракта и закона. Зачем вам приучать людей брать на себя не чем не обеспеченные обязательства?
Чет какая то каша.
Зачем нужны все эти ваши грэйды, если в итоге все мешается в кучу?
Даже сама подача "тупо кодить"… Это как? В итоге с таким полходом и получаются те самые костыли… Грэйды эти и нужны, чтобы отделить функционалов и механиков от архитекторов и аналитиков. Которые, кстати, тоже не должны лезть в "что продавать"… А должны обсуждать хотелки и бить по рукам бизнесу, так как от "бизнеса" можно ожидать, порой, фантасмогорически нереальный поток сознания. Там тоже люди, которым надо оправдывать свою зарплату.
И все эти "а давайте.." стоят тоже денег…
Итого.
Бизнес должен генерить идеи о том что и кому и как продать
Аналитики должны оценить затраты, требуемые ресурсы (которых как правило нет) и довести до бизнеса.
Архитекторы должны составить план как, чем, кем, когда, на чем.
Программисты должны реализовать в рамках девопса.
Все.
Все остальное — муть
Грэйды эти и нужны, чтобы отделить функционалов и механиков от архитекторов и аналитиков.
Неа, не нужны для этого грейды. Для этого нужны специальности. "Архитектор" — это не грейд, это специальность или профессия.
Так тимлид может занимать должность ведущего просто потому что в данный момент нет свободных должностей главного. Но по деньгам получать как главный.
А суть в том, что должно быть разделение обязанностей. Архитектор, аналитики, разработчики. Ну или всякие консультанты направлений, руководители направлений, аналитики, разработчики. И у каждого свой круг ответственности.
И поток сумеречного сознания бизнеса в первую очередь попадает на аналитика. Который вычленяет из него нечто разумное, отметает неразумное и вообще приходит к некоему консенсусу с заказчиком. На основе которого и рождается ТЗ для разработчиков.
Зачем нужны все эти ваши грэйды
Затем, чтобы всегда была готовая формальная причина платить меньше.
Тут похоже просто произошло недопонимание терминов между сторонами.
Это в условной статике. Есть ещё фактор карьерного роста, ну или перемещения. Если хочешь занять другую позицию, то во многих случаях хорошей стратегией может быть постепенное взятие на себя ответственности с этой целевой на себя. Может в рамках одной компании, может переходя по компаниям формально по одной позиции, той же сеньорской, но в которой всё меньше и меньше будет "тупого" программирования, и всё больше и больше будет "должностных обязанностей" целевой позиции. Ведь те же формально сеньоры нередко выполняют и роли и лидов, и архитекторов, и бизнес-аналитиков, являясь единственным человеком в компании, способным эффективно переводить даже не требования, а "хотелки" бизнеса в язык технических задач, ну или убдительно их отклонять или сильно модифицировать.
В интересах заказчика всегда нанять 1го человека, который сделает все
… это пока заказчик не упирается в бас-фактор или невозможность распараллелить что-то.
Всё гораздо проще: вынуть программиста (продавца, менеджера, директора) из бизнеса и пусть зарабатывают себе на жизнь как заблагорассудится. А покамест в обойме — пусть все трое пашут как миленькие на благо общего дела и, как СЛЕДСТВИЕ — своего кармана.
Разве есть другие варианты?
"Лычки" позволяют хоть и в широком диапазоне, но хоть как то идентифицировать "уровень" исполнителя. Далеко не всегда зарплата и опыт (если мы говорим про размер, ну например 5 или 10 лет опыта) идентификатор. Может ли быть размер зарплаты "сеньора", а навыки далеко нет? Конечно и что удивительно — это не редкость. Может ли быть большой опыт, а фактически человек очень мало знает и умеет? Тоже может и тоже не редкость.
может быть нужно просто выполнять свою работу качественно?
Тут, знаете ли, важный вопрос — а где кончается "своя работа" и что такое "качественно".
своя работа ограничена должностной инструкцией
Это плохо сочетается с "руководство не ошибается". Потому что инструкцию ту тоже руководство писало.
качественно-чтоб потом не переделывать
… видимо, рефакторинг надо заклеймить как признак некачественной работы.
то, что коней на переправе меняют, кодера не должно волновать
Если ваша позиция "меня это волновать не должно", то я прекрасно ее понимаю. Только вот с моим пониманием качественной работы это не сочетается.
Это плохо сочетается с «руководство не ошибается». Потому что инструкцию ту тоже руководство писало.
Дело не в том, что оно писало что-то, а в том, что написанное оторвано от реальности в угоду формальности, а вменяемое не вменяемо.
… видимо, рефакторинг надо заклеймить как признак некачественной работы.
в рефакторинге ключевое слово — контролируемый и оно относится к изменению условий жизни. качество это устойчивость.
А отсутствие качества это то, что не поддается контролю, а генерирует не сбои.
написанное оторвано от реальности в угоду формальности
И? Если "своя работа ограничена инструкцией", как написано в комменте, на который я отвечал, то какая разница, оторвана ли инструкция от реальности?
в рефакторинге ключевое слово — контролируемый и оно относится к изменению условий жизни.
Я не понимаю, что вы хотите сказать. Рефакторинг — это, неизбежно, переделка. Если "делать качественно — это чтобы не переделывать", то рефакторинг — это признак того, что раньше было сделано некачественно.
Ну, одно дело "проблемы", а другое — "задачи"...
Я понимаю, что на хабре в основном айтишники и им это приятно, что мол разработчики ворочат бизнес на кончиках пальцев, но я как и айтишник и бизнесмен скажу вам, что разработка программного обеспечения и проблемы бизнеса — это СОВЕРШЕННО РАЗНЫЕ понятия. Конечно же будет пересечение, но только БИЗНЕС диктует развитие бизнес ценностей.
Разработчик как профессионал должен выполнять поставленные задачи и реализовывать их качественно, СОГЛАСНО ТЗ. Это его должностные обязанности.
Менеджер по продукту, например, решает как будет выглядеть то или иное решение. И если раработчик начинает спорить с ним и делать по своему, то он лезет в чужие обязанности.
Так можно по каждой позиции пройтись внутри команды и конечно команда может обсуждать те или иные решения, но ответственность принимает в конечном итоге каждый за СВОЮ область обязанности.
И теперь скажите, ГДЕ у разработчика и КАКИЕ бизнес проблемы?
Слушайте, хватит уже второй статьей разводить бред от непонимания, что такое должностные обязанности и что такое проблемы бизнеса?
А почему вы считаете, что вы правильно понимаете, что такое "проблемы бизнеса", а остальные — нет?
Разработчик как профессионал должен выполнять поставленные задачи и реализовывать их качественно, СОГЛАСНО ТЗ. Это его должностные обязанности.
А вот это ТЗ, которое он реализует, оно зачем?
А почему вы считаете, что вы правильно понимаете, что такое «проблемы бизнеса», а остальные — нет?
Как минимум потому что имею отношение к созданию и развитию бизнеса.
А вот это ТЗ, которое он реализует, оно зачем?
Чтобы создавать бизнес ценности, которые хочет реализовать бизнес. То есть поймите, направление идет сверху вниз, а не наоборот. Хотите указывать бизнесу, какие создавать ценности — кто же мешает стать техническим директором, архитектором и прочее?
PS. И не надо пожалуйста передергивать факты?) Это видно на IT форуме.
Как минимум потому что имею отношение к созданию и развитию бизнеса.
Это значит только то, что у вас есть видение "проблем бизнеса", которое верно в рамках вашего бизнеса. Не более.
Чтобы создавать бизнес ценности, которые хочет реализовать бизнес.
… а это не решение проблем-задач бизнеса разве?
Хотите указывать бизнесу, какие создавать ценности
Нет, не хочу. Но это не значит, что я их — ценности — не создаю.
И не надо пожалуйста передергивать факты?
Факты? Какие факты? Я пока вижу только суждения и мнения, не более того.
Это значит только то, что у вас есть видение «проблем бизнеса», которое верно в рамках вашего бизнеса. Не более.Это по-моему очевидно, нет?
… а это не решение проблем-задач бизнеса разве?Проблемы и задачи — совершенно разные вещи, это раз. Решение задач — да, для этого и нанимают персонал.
Нет, не хочу. Но это не значит, что я их — ценности — не создаю.Вы разницу видите между планированием и реализацией? Между планированием и решением? Между проблемами и задачами? Это же причино-следсвенные зависимости.
Факты? Какие факты? Я пока вижу только суждения и мнения, не более того.Я никак не ставлю себя в противовес сообществу. Я обращаю внимание на то, что основываясь на непонимании простых понятий, уже вторую статью разводят дисксуссию. Это к вашему самому первому вопросу в первом комментарии.
Это по-моему очевидно, нет?
Нет. Потому что статьи — они не про ваш бизнес, а про бизнес вообще, но вы все равно говорите, что они неправильные.
Проблемы и задачи — совершенно разные вещи, это раз.
Разные, но связанные. Большая часть задач (в моем личном опыте наблюдения) — это решение тех или иных проблем.
Вы разницу видите между планированием и реализацией?
Вижу. Из этой разницы, однако, никак не следует, что люди, занимающиеся планированием, или люди, занимающиеся реализацией, не создают ценностей.
Я обращаю внимание на то, что основываясь на непонимании простых понятий
И вы делаете то же самое.
задача у бизнеса одна-получить прибыль
… а как же декомпозиция, так близкая сердцу программиста?
программист исполнитель
… а исполнителю работу декомпоновать не надо? Или уже все приносят готовыми кусочками по методу-или-что-у-вас-там-минимальная-структурная-единица, не больше часа на разработку?
С каких пор декомпозиция работы — это отсебятина?
Если у руководства было мнение о декомпозиции, оно могло бы его и выразить, правда?
руководству важен результат, а не то, какими путями задача решается.
Вы себе противоречите. Если руководству важен результат, а не пути решения, то как мнение программиста о путях решения может не совпадать с мнением руководства?
"Например" чего?
Я не очень понимаю, пример чего вы пытаетесь привести.
А это здесь к чему, простите?
Вы уж определитесь, то ли "бизнес не знает как решить проблему", то ли "отсебятину, программисту, лепить непозволительно".
а тут и определяться нечего
Так выберите одно.
то с вашего позволения предлагаю закончить
Неа, я вам такого позволения не дам.
Вы меня с кем-то перепутали.
когда вам указывают на то, что нечего перекладывать ответственность на других, что «бизнес» должен найти, подготовить и нести ответственность за решение проблемы сам, а все остальные (не только программеры) это решение должны реализовать в рамках своих обязанностей лезете в бутылку и там надуваете щеки.
А по-моему, вы то ли меня с кем-то путаете, то ли читаете в моих словах то, чего я не писал.
действительно типичный представитель бизнеса ведет свой диалог именно так
Именно как?
программисты должны решать и задачи бизнеса и свои задачи.
Это вы приписываете бизнесу или мне? С моей точки зрения, программисты (конечно, работающие на бизнес, а не вообще все программисты в мире) должны решать в первую очередь задачи бизнеса. Свои задачи у них возникают либо как очень далекая производная бизнес-задач, либо просто потому, что все мы люди, и хотим иногда что-то поделать для себя.
и желательно бесплатно.
А этого ни я, ни (разумный) бизнес не ожидает.
когда вам указывают на то, что нечего перекладывать ответственность на других
… то я с этим соглашаюсь, потому что я нигде не призывал перекладывать ответственность.
«бизнес» должен найти, подготовить и нести ответственность за решение проблемы сам
Не, не должен. Почему бы?
Или вы считаете, что программист не несет ответственности за то, что его код работает так, как ожидалось в поставленной задаче?
все остальные (не только программеры) это решение должны реализовать в рамках своих обязанностей
А чем определены, собственно, "рамки обязанностей"?
Да где вы видели "разумный бизнес"… только в книжках. В реалиях взять любую контору что коммерческую, что гос.контору везде одно — получить максимум прибыли/плюшек при минимуме затрат.
Да. Должен.
Именно представитель от бизнеса. Должен. Это его обязанности.
Не прлграммист доджен планировать. Не сетевик не админ.
А все потому, что в " бизнес" лезут дитлетанты, нахватавшиеся модных словечек, но связать их в осмысленное предложение не в состоянии. И получается у нас 7 перпендикулярных прямых. Делать ничего не хотим и не умеем, зато умеем (как опрометсючиво кажется ) "жонглировать" словами и смыслами. По факту топорно и бездарно.
И любой грамотный программер влегкую ткнет вас, "генераторов бизнес идей" носом в инструкции и сферы ответственности, регламенты, положения и т.д...
Да где вы видели "разумный бизнес"…
На работе.
везде одно — получить максимум прибыли/плюшек при минимуме затрат.
Только если вы очень широко это трактуете. Потому что подход "затратить побольше сейчас, чтобы получить побольше прибыли потом", внезапно, тоже встречается.
Именно представитель от бизнеса. Должен. Это его обязанности.
А, простите, где конкретно эти обязанности записаны?
И любой грамотный программер влегкую ткнет вас, "генераторов бизнес идей" носом в инструкции и сферы ответственности, регламенты, положения и т.д...
Вы считаете себя грамотным программером?
(Занятно, кстати. Вы не считаете, что программист не должен планировать, но при этом считаете, что программист — любой грамотный! — разбирается в должностных инструкциях, регламентах и положениях. Хотя, внезапно, умение разбираться в регламентах и положениях — это именно то, что иногда нужно, чтобы писать бизнес-требования.)
Да где вы видели «разумный бизнес»… только в книжках. В реалиях взять любую контору что коммерческую, что гос.контору везде одно — получить максимум прибыли/плюшек при минимуме затрат.
Это нормально для бизнеса.
Другое дело, как определяется этот минимум. И что в этот минимум входит.
Если вы попали в бизнес, где к вам относятся как к расходному материалу… Ну не повезло. Но бывает и иначе. Возможно, дело еще в специализации разработчика и количестве претендентов на это место. Или в специализации бизнеса.
У нас есть такой класс задач как оптимизация уже работающего кода. Выглядит это примерно так:
Бизнес: загрузка сервера в пике превышает 95%. Это проблема и с этим надо что-то делать.
Заметьте — в данном случае бизнес понятия не имеет как эту проблему решать. Но он ее четко формулировал.
Дальше в дело включаются специально обученные товарищи — аудиторы. Иногда свои из сопровождения, но обычно раз в год приглашаются специалисты из IBM (речь идет о серверах IBM i).
Они что-то там как-то измеряют, исследуют и выкатывают длинный список типа:
в модуле ххххх слишком часто производятся операции с датами что занимает 27% процессорного времени модуля.
в модуле уууууу при каждом запуске производится чтение из dtaara что занимает 18% процессорного времени
в модуле zzzzzz слишком много переоткрытий файлов, 36% процессорного времени
в модуле wwwww постоянно происходит формирование sql запроса на лету — 29% процессорного времени.
Дальше уже работа для разработчиков — каждый такой модуль рассматривается «под микроскопом» на предмет того что можно улучшить.
Потом тесты на неухудшение (сначала сравнеи результатов старой и новой версий, потом нагрузочнойе тестирование). Если все хорошо — внедрение.
Как-то так все это выглядит.
Задачи на оптимизацию даже не для всякого мидла — там требуется крепкое знание особенностей работы платформы, системных API. Иногда приходится часть модулей переписывать с RPG (основной язык) на С (более низкоуровневый по сравнению с RPG).
И это «внеплановые» задачи. Т.е. их надо как-то вклинивать в свой план так, чтобы основное не страдало.
Но это как раз тот пример, когда бизнес не может знать как решать проблему и отдает это на откуп специалистам.
В конце концов, разработчик, когда идет на собеседование на новое место работы, тоже должен оценивать что его ждет — или ему обещают побольше денег, но видно, что в конторе нет нормально выстроенного workflow, когда все ТЗ будут формулироваться в стиле «сделайте нам красиво», причем в ходе работы (когда у тебя уже выстроена архитектура задачи) к тебе будут прибегать «а вот нам пришла еще гениальная идея — ее тоже надо как-то присрать к проекту» при том, что новая фича в архитектуру не вписывается от слова никак.
Или же денег вроде как поменьше, но есть четкая организация рабочего процесса, документирование на каждом этапе, четкое ведение задач и четкое разделение обязанностей и ответсвенности. И понимание того, что чтобы корова давал больше молока, за ней надо хорошо ухаживать.
Я лично выбираю второй вариант ибо за долгое годы в разработке шишек себе набил преизрядно и повидал многое.
И со всякими мелкими ООО «Сукин и Сын» предпочитаю не связываться — там нет перспективы. Если, конечно, это не твой личный проект где ты будешь работать больше ради того чтобы его поднять, а не только ради денег.
Возможно поэтому у меня не возникает вопросов должен программист решать проблемы бизнеса или нет — бизнес меня своими проблемами не грузит. Он формулирует задачи, которые я могу решить в рамках своей компетенции и создает мне условия для наиболее эффективного их решения.
Я по образованию вовсе не итшник. Меня учили быть секретным физиком (да, в дипломе написано «Техническая физика» и номер специальности, а что за этим стоит уже знает тот, кому положено знать). Более того, если бы мне в институте, когда был курс «Основы вычтехники» сказали бы что я стану разработчиком, ни за что не поверил бы:-)
От распределения в какое-нибудь ЗАТО удалось открутиться, попал в один институт в система РАН. Продержался там 3.5 года, за которые понял что академическая наука не для меня. Отчасти из-за скотского отношения (характерного для всей системы РАН — много знакомых там работали или работают) — система чисто армейская — я начальник, ты дурак. Тебя могут грузить всем что попало. Ты аспирант или соискатель? Ну так тебе дисер нужен, давай работай. Нужно установку делать? Делай! Материалы, детали — все сам ищи. Нужен токарь? Найди. Заплати ему из своих («у института нет возможностей») — это ж тебе дисер нужен, у нас уже есть…
Опыт как не должно быть оказался очень познавательным. И полезым. Единственное, что отуда вынес — понимание что хочу заниматься программированием. Ну так получилось что пришлось заниматься обработкой данных, а толковых пакетов в те годы не было. Писал сам «Прикладной регрессионный анализ» Был настольной книгой и в значительной мере был перенесен в код.
Но все остальное довело практически до депрессии. Поэтому когда пришел знакомый и сказал «тут одна бизнесструктура создает коммерческую биржу и им нужны программисты» я просто пришел к начальству и сказал «вот заявление, хотите подписывайте, хотите нет, но с сзавтрашего дня меня тут не будет, за трудовой приду через месяц». Был, конечно, скандал, но это отдельная песня.
Дальше было много чего. В том числе и свой проект (по сути стартап, но тогда таких слов еще не знали), который подняли с нуля небольшими силами.
В конечном итоге, когда в последний раз менял работу, был выбор — мелкая конторка, которая занималась разработкой плагинов к системе архитектурного проектирования (плагины в основном направлены на осмечивание проекта и выгрузку данных в 1С). Удаленная работа, неплохие деньги, но… Полтора землекопа и полное отстутствие сколь бы то ни было внятной перспективы сколько это проживет и куда движется.
И тут в последний момент звонок из банка — давайте встретимся, поговорим. Пошел чисто ради интереса. Разговор получился очень доброжелательный — в теми людьми с которыми сейчас работаю. Рассказал чем занимался и что умею, мне рассказали что и как у них. И понял что ХОЧУ! Хочу тут работать. Несмотря на лютый легаси, кровавый энтерпрайз, несмотря на новый язык (RPG), абсолютно незнакомую платформу (IBM i, она же AS/400)…
Но тут настолько все четко организовано во всех отношениях. И отношения бизнес — разработка построены на взаимопонимании и стремлении к нахождению взаимоудовлетворяющих решений.
Ну и просто отношение к работнику как к активу, который нужно использовать с максимальной эффективностью (а это не только требования, но и создание условий). К примеру, на удаленку всех, кого можно, начали переводить еще до введения официальных карантинов. Просто чтобы минимизировать риски и сохранить квалифицированные кадры. Хотя это потребовало немалых вложений со стороны банка — организовать каналы связи и все доступы с учетом всех требований УИБ достаточно хлопотное занятие — сопровождение и поддержка в три смены работала.
В целом я сейчас вижу на собственном примере как все это должно быть в варианте близком к идеальному.
В одном из выступлений генеральный управляющий сказал что в условиях кризиса политика банка не только в сохранении своих кадров, но и в привлечении новых квалифицированных специалистов (из тех, кого вынужденно сократили в других местах).
Отчасти это еще связано со спецификой ИТ подразделений — готовых спецов в RPG и AS/400 в РФ очень мало (насколько я знаю, на этой платформе работает Альфа, Росбанк и Райф, ну может еще несколько контор вне финтеха). Т.е. в любого нового работника надо сначала вкладываться в обучение.
Естественно, что приветствуется проактивность и не приветствуется позиция «я человек маленький, хожу сюда за зарплатой».
Проактивность материально стимулируется — в прошлом году объявили повышение ФЗП на 5%. Конкретные цифры на усмотрение руководителей подразделений.
Позиция руководителей была такая — повысить всем на 5% скучно. Так что выбираем достойных и повышаем им. Без ложной скромности — мне повысили на 25% :-)
Плюс индивидуальные коэффициенты для рассчета годовых бонусов (базовый — 15% от годового оклада). Личный коэффициент по итогам работы может достигать 1.5. В целом это достаточно ощутимо в денежном выражении.
Т.е. с тебя требуют по максимуму, но и материально стимулируют если есть отдача.
При том, что никакой благотворительности нет и в помине. Ключевой вопрос — сколько на этом заработает банк. Просто разумный подход — схантить хорошего спеца, вложиться в него, простимулировать, получить отдачу. В результате всем хорошо и все довольны. Есть понятный вектор развития, есть четкие приоритеты, обязанности и ответственность.
А я вот предпочитаю первые, где минимальна вероятность услышать "не лезь не в своё дело". Это если выбирать между двумя крайностями.
Зато переобуться в воздухе в мелких конторах практически норма. А потом ты же виноват в срыве сроков проекта в котором ТЗ меняется быстрее чем ты успеваешь его реализовывать — «пока противник рисует карты, мы меняем рельеф местности».
Вообще, понимание что ТЗ должно быть намертво зафиксировано до начала разработки, а все свежие гениальные идеи должны откладываться в todo лист пришло достаточно давно. Даже для своих проектов.
Только так можно обеспечить сдачу проекта в срок без адских преодолений и бессонных ночей за монитором.
С изменением ТЗ я нахожу хорошим компромиссом Скрам: с одной стороны, требования зафиксированы. С другой, всего на неделю-месяц каждый проект, так что бизнесу долго ждать не нужно будет.
Ну и тяжёлая артиллерия есть: отмена спринта. Отменяем проект и начинаем планировтаь новый.
Отмените проект, начнете планировать новый, а в это время конкуренты отхватят ваш кусок рынка. Иногда это приходится учитывать и быстрее выкатить заведомо более слабую версию просто чтобы закрепиться на рынке. А потом уже ее развивать.
У нас такое было когда пилили свой проект по системе мониторинга инженерного обрудования зданий.
Поначалу основная проблема была в том, чтобы убедить заказчика в том, что ему это нужно (начинали с нуля, ничего подобного не было тогда, но эта тема для отдельной статьи). Вплоть до того, что пилоты ставили за свои деньги просто с условием что эти объекты будем сами обслуживать.
Потом появились конкуренты. И там уже вопрос был кто первый застолбит поляну — если мы поставили свое обрудоваание и развернули свою систему, то клиент с нее уже так просто не соскочит — это не софт переставить, там куча оборудования монтировать нужно. И тут вопрос чато в том, кто первый успеет и предложит лучшие условия пусть и с меньшим функционалом (плюс «фьючерс» что будет новая версия с учетом хотелок клиента).
В тех условиях выход был только в жесткой фиксации ТЗ и соблюдении сроков поставки.
Сейчас тоже такое бывает — задачи идут валом, есть план. И если по какой-то из них заказчик вдруг начинает вертеть хвостом и менять хотелки, ему просто говорится — есть утвержденное BRD, работаем по нему. Хотите что-то еще — делаейте новую заявку на разработку и в очередь (BRD — оценка — FSD — разработка — тестирование — внедрение). Мы поставим в план и сделаем.
Очень, кстати, дисциплинирует, в том числе и заказчика. А то был случай когда с отчетом, который делается за неделю провозились два месяца (аналитик 4 раза ТЗ передалывал). Заказчик начал выделываться на бизнестесте — «а вот тут у нас три клиента в отчет не попадают, а нам кажется что должны попадать». Делаю полный трейслог, показываю — «у вас были сформулированы условия отбора клиентов, эти трое не проходят вот по таким параметрам». Заказчик «а давайте условия поменяем»… И начинается подгонка под ответ…
Вот такого надо избегать всеми силами.
А при чем тут делегирование?
Нет, не понимаю.
И да, если бизнес — это набор обязанностей, а не задач, то откуда берутся задачи?
Бизнес менеджемент издает законы, программисты и другие их исполняют.
Если вы делаете и то и другое, значит вы просто совмещаете разные должности. Но у вас рано или поздно начнутся конфликты между исполнителем и законодателем в одном лице в виде «7 линий перпендикулярных друг другу».
Бизнес менеджемент издает законы, программисты и другие их исполняют.
Смотрите. Вот написано было: "задача у бизнеса одна-получить прибыль". Это, в вашем примере, закон? Или что?
Или вы считаете, что учредитель открывает джиру, читает эту задачу и чешет репу как ее выполнить?)
Это аксиома) Да, можно сказать закон.
Вот вы только что написали:
Бизнес менеджемент издает законы, программисты и другие их исполняют.
Получается, что бизнес-менеджмент издает закон "получить прибыиль", программисты и другие этот закон выполняют. Так? Или нет?
Получается, что бизнес-менеджмент издает закон «получить прибыиль», программисты и другие этот закон выполняют. Так? Или нет?Получается что получение прибыли в вашем понимании является законом, изданным менеджементом?) Т.е. к вам начальник приходит и говорит — хочу получить прибыль, сделай код?))))
Канонически получение прибыли — цель бизнеса, а не задача. Задачи направлены на достижение цели, например "построить завод, запустить и продавать продукцию выше себестоимости" или "написать софт, продавать его выше себестоимости" и т. п.
Нет. Потому что статьи — они не про ваш бизнес, а про бизнес вообще, но вы все равно говорите, что они неправильные.А бизнес вообще не включает мой бизнес? Вы себе противоречите.
Разные, но связанные. Большая часть задач (в моем личном опыте наблюдения) — это решение тех или иных проблем.Опять же причина следствие, не мешайте в кучу.
Вижу. Из этой разницы, однако, никак не следует, что люди, занимающиеся планированием, или люди, занимающиеся реализацией, не создают ценностей.Создание ценностей и решение бизнес проблема — вещи разные.
А бизнес вообще не включает мой бизнес? Вы себе противоречите.
"Бизнес вообще" включает ваш бизнес, но именно поэтому то, что неверно для вашего бизнес не обязательно неверно для бизнеса вообще.
Опять же причина следствие, не мешайте в кучу.
А какая разница, что причина, а что следствие? В итоге решив одно, все равно решаем другое.
Создание ценностей и решение бизнес проблема — вещи разные.
Разные. Но решение бизнес проблемы обычно создает ценность.
Программист по должности вполне может исполнять роль архитектора в жизненном цикле продукта. Чуть ли не в половине сеньорских вакансий архитектурные навыки требуются.
А кто может написать качественное ТЗ для программиста? Не говоря о том, что чаще всего именно ТЗ нет.
Все задачи бизнеса решает менеджер. Это классика. Почитайте любой учебник. Но в России менеджером называют кого угодно кроме заложенного изначально в этот термин — управленец! Менеджер (и только он) для решения задач бизнеса ставит задачи подчиненным, которые тоже могут иметь подчиненных. Но сам не занимается выполнением чего-либо. Это принципиально важно!
Проблема в том, что менеджеров, способных управлять программистами, практически нет. Вот и пытаются создать их насильно. Это возможно, но не обязательно. И уж точно не связано напрямую с уровнем программиста. Даже наоборот, программтст начального или среднего уровня, имеющий способности и желание к управлению (руководству) справится с этим лучше, чем высококлассный программист без желания и/или способностей к управлению. Это разные люди.
Все задачи бизнеса решает менеджер.
Сам?
И я так и не увидел вашей позиции, только вопросы на вопросы. Складывается ощущение троллинга.
Задачи да, это его обязанность. А вот реализует их разработчик.
Как можно решить задачу, не реализовав соответствующую функциональность?
И я так и не увидел вашей позиции, только вопросы на вопросы. Складывается ощущение троллинга.
Как можно решить задачу, не реализовав соответствующую функциональность?Скажите, кто принимает решение в вашем теле о том, чтобы идти по земле, ноги или мозг?
И теперь скажите вы считаете, что именно ноги занимаются решением КУДА идти? Вот КУДА — это и есть проблемы бизнеса, а перемещение — это выполнение уже заданных КУДА.
И теперь скажите вы считаете, что именно ноги занимаются решением КУДА идти?
Я считаю, что именно ноги занимаются решением задачи "доставить меня в точку".
У нас точно не случилось путаницы между решением задачи (solution) и принятием решения (decision)? Потому что это два совершенно разных процесса.
«Задача бизнеса», о которой писали выше — это design.
А, простите, из какого формального общепринятого определения вы это взяли?
Например, стоит задача увеличения прибыли на 1 млн рублей. Организуется митинг менеджеров и создается дизайн/архитектура решения данной задачи на высоком уровне планирования.
Причем тут вообще программист?
Да хоть отсюда, например: utmagazine.ru/posts/8985-biznes-zadachi
О, спасибо.
"Постоянные задачи бизнеса – это такие задачи, которые предприятие будет осуществлять на протяжении всего периода своего развития. [...] Так, например, задачей косметической компании является выпуск косметики."
Если посмотреть на компанию-разрабочика ПО, то ее "постоянной задачей бизнеса" является выпуск ПО. Следовательно, разработчик внутри решает "постоянную задачу бизнеса".
Что, собственно, и надо было доказать.
Например, стоит задача увеличения прибыли на 1 млн рублей. Организуется митинг менеджеров и создается дизайн/архитектура решения данной задачи на высоком уровне планирования.
Прекрасно. Вот вы создали дизайн/архитектуру. Эта ваша задача увеличения прибыли — она решена? В том смысле, что прибыль увеличилась?
Почему-то многие думают, что для того что-бы заработать нужно делать крутой софт и решать реальные проблемы, у меня плохие новости:
можно ПРОДАТЬ имитацию чего угодно (по красивому привлечь инвестиции).
Остальное (сеньоры, мидлы, индус-гастарбайтеры) — способы, средства и вопрос компетенции и возможностей.
Инструмент, который подбирают под задачу и укладывается в рамки бюджета.
Но так не всё работает. Как минимум крупный интерпрайз так не работает. Об этом уже писали, я ещё раз сакцентирую внимание на том что для каждой отрасли есть свои специалисты. Бизнес-аналитики/продакт овнеры собирают требования. Архитекторы делают архитектуру. Девы — делают по этому инпуту систему. Допустим я — участник команды которая делает микросервис, один из 15 типов. Нам дают описание — вот такой АПИ сервиса. В этом случае делаете Х, в этому — Y. Всё. И технологии уже выбраны — база такая, брокер сообщений такой, язык программирования такой, фреймворк такой.
Где тут решать проблему бизнеса? Прийти и рассказать что я могу по-разному написать возврат json-а? Более того, если я сделаю что-то не по требованиям, допустим сделаю другую аутентификацию — вряд ли кто-то будет рад этой «инициативе».
Я заметил что и в прошлой статье и в этой много путаницы в терминах. Сбор требований — это не решение проблем бизнеса. То как разместить кнопку на лендинг странице — это тоже не решение проблем бизнеса.
Это сугубо моё субъективное мнение, НО: в мире есть довольно мало специалистов такого уровня, которые действительно решают проблемы (или задачи — как хотите) бизнеса. Мало таких инженеров которые пришли к своим боссам с пропозалом которым стал историческим и дал жизнь чему-то что принесло миллионы.
Сегодня на хабре была статья про Боинг. habr.com/ru/post/501256
Вот что я думаю: инженеры должны заниматься инженерией и пытаться сохранить инженерную культуру, насколько это возможно. Иначе нас ждёт много булшита, сделанного на скорую руку, чтобы «решить проблемы бизнеса». Сейчас наступила эпоха сверхбыстрой разработки, но качество ухудшилось. Я хочу сказать что было бы хорошо если бы бизнес научился ценить специалиста и инженера который просто умеет делать свою работу и делает это хорошо, даже если он не придумал как собственнику заработать ещё один миллион.
То как разместить кнопку на лендинг странице — это тоже не решение проблем бизнеса.
А вот предложить создать сеошный лендинг, а не тратить хз какие бюджеты на рекламу основного сайта с минимальной конверсией — вполне себе решение проблемы бизнеса "очень большая стоимость привлечения"
Никто, обычно, не ожидает экспертных знаний в домене от вновь пришедшего сеньор-разработчика, если в резюме намёка на это нет (разве что какие-то специфические разработчики типа 1С-разработчиков). Но, по-моему, если ты решил работать в компании несколько лет, то уже имеет смысл погружаться в домен. Может даже до начала разбирательства в технической части.
Ну, если конечно, ты планируешь делать бизнес-таски, а не идёшь на роль "оптимизатора наносекунд"
>Ну, если конечно, ты планируешь делать бизнес-таски, а не идёшь на роль «оптимизатора наносекунд»
кто такой «оптимизатор наносекунд»?
Мне сложно представить чтобы от знаний домена на уровне «во саду ли в огороде» был какой-то толк.
Конечно, верить что ты-де не просто винтик, и не просто код пишешь а решаешь проблемы бизнеса — само собой более приятно ))
кто такой «оптимизатор наносекунд»?
Технический специалист, способный заметно оптимизировать средней руки софт.
Мне сложно представить чтобы от знаний домена на уровне «во саду ли в огороде» был какой-то толк.
Ну, например, не может быть толка от знаний программиста, что некоторые вроде успешные оплаты картой онлайн могут быть отменены, причём сильно не сразу?
Вы имели в виду толк от программиста который работает над банковской системой или который интегрирует оплату картой на сайте?
Это полезное знание. Вот только как таких раздобыть? :) Я работаю в аутсорсе, как-то не удаётся освоить хорошо какой-то домен.
в целом такие знания безусловно полезны, но их надо как можно больше — чем их больше, тем больше шансов помочь бизнесу
Где тут решать проблему бизнеса?
А вот прямо там, где вы микросервис пишете. Этот микросервис — он же не просто так, покрасоваться? Он зачем-то бизнесу нужен (если не нужен, тогда разговор другой, намного более грустный). Значит, когда вы его пишете, вы решаете бизнес-проблему (или бизнес-задачу, если проблемы изначально не было).
Так и нет вопросов с этим сервисом. Весь сыр-бор оттого, что автора, вместо того чтобы реализовать действительно нужную вещь, заставляют высосать из пальца новый микросервис, да чтоб не меньше тысячи шкурок принес.
Весь сыр-бор оттого, что автора, вместо того чтобы реализовать действительно нужную вещь, заставляют высосать из пальца новый микросервис
Так это ровно обратно решению проблем бизнеса как раз.
да чтоб не меньше тысячи шкурок принес.
Ну, от нас регулярно просят сделать что-то, что мы не умеем или не можем. Так бывает.
В этом случае максимальное количество подводных камней, которые случаются всегда, удалось решить командным взаимодействием.
Вот где-то на этой строке бизнес превращается в сказочную страну с кисельными берегами.
Потому что в реальности и после этого "сорваны сроки, костыли, передача ответственности друг другу, потом, как правило, очень долгое исправление правок и добавление "новых пожеланий заказчика"" ©, разве что не "потом" а "одновременно". Хотя бы и по той причине, что пункт "добавление новых пожеланий" от этапа планирования не исчезает, а всё остальное из этого проистекает.
Не говоря уже о том, что разработчики могут кардинально изменить реализацию проектов, потому что бизнес может понимать неправильно что для этого нужно.
А может неправильно понять задачу бизнеса уже разработка. Например, от недостаточности бизнес-важных данных, потому что они не на их уровне.
И под командой я подразумеваю не пару кодеров, которые реализуют проект, а всю компанию.
Когда в проекте сотня-две-три человек — команды нет и быть физически не может. Есть отделы, кланы и группы, как бы они не самоназывались и как бы не вещали про "one team".
Нижнюю границу "тут уже не команда" определить затрудняюсь, но чую, что она невысока и касается нескольких десятков человек. Возможно, не более двух.
Я люблю программировать, и получаю от этого удовольствие. Код — это моя стихия.
Когда программирование и бизнес смешиваются, это становится скучно и нудно.
Если была возможность не работать, я бы пилил только свои опенсорс проекты, или занимался исследованиями.
Программист должен ПРОДАВАТЬ? Нет конечно, хотя навык далеко не бесполезный, особенно на высоких позициях. Можно ли просто кодить? Конечно, можно. Может ли Senior просто кодить? Нет, на просто кодить можно взять мидла.
Вы противоречите сами себе. Сеньор получается не программист?
Программист должен решать проблемы бизнесаСоглашусь с заголовком статьи только в одном случае: если бизнес, в свою очередь, качественно решает проблемы/задачи пользователя, а не впаривает ему с помощью отделов маркетинга/продаж всякую каку, заботясь лишь о собственной/личной прибыли и ублажении инвесторов.
— красноречие авторов склоняет читателей на свою сторону, хабралюди — это люди, в общем-то, с ещё несложившимися мировоззрениями, на их мнение можно легко повлиять, красноречиво выразив свою точку зрения;
— в целом голосовать склонны более те читатели, которые настроены позитивно к теме статьи, а те, что отрицательно, — скорее воздержатся от голосования.
Как по вашему мнению, для чего проводится голосование и что оно отражает, есть ли в нём какие-то более интересные факты, чем те что на поверхности?
Этот пример обычно приводится на семинарах по тимбилдингу, просто вспомнилось.
Кому и что должен программист решается в каждом конкретном случае, исходя из должности, должностных инструкций, корпоративной культуры, личности программиста и его планов на дальнейшее развитие. Где-то достаточно, чтобы сотрудник отсидел положенные 8 часов, выдал «на гора» N строк кода. Где-то сотрудники вовлекаются в процесс, чтобы делались удобные на выходе решения.
Отличное мнение, коллега, только с моей колокольни вы упускаете одну важную деталь.
Дело в том, что бизнес САМ идентифицирует какая у него проблема (а зачастую решение тоже определяет) и отдаёт её разработчику-проблематологу в виде указания "решай вот эту проблему" (зачастую добавляя "вот таким-то образом").
Когда оказывается что проблема идентифицирована неверно, или же что решение, которое хочет бизнес к этой проблеме не подходит (или и то и другое сразу) — в кого летят шишки? Правильно, в разработчика. Не станут же люди на ответственных должностях признавать свои ошибки. В результате получается ситуация:
— Мы аэропорт, мы терпим убытки. Это от того, что мы мало продаём.
— Но…
— Мы приняли решение что наша проблема решится если засадить взлётно-посадочную полосу картошкой.
— Эээ… Но…
— Никаких но, решай проблему бизнеса. Вот проблема, вот тебе даже способ решения. Иди вскапывай ВПП и сажай картошку.
(через время)
— Взлетающий самолёт увяз в грязи, мы неделю его вытаскивали, все рейсы отменились, мы терпим убытки! Кто там занимался этой проблемой?
— Я, но эм…
— Уволен!
Поэтому лично мне такие разговоры и не нравятся — бизнес часто (не всегда, но часто) ставит задачи, а когда выясняется что задачи определены неправильно, оговорка "разработчик должен решать проблемы бизнеса" используется для того, чтобы спихнуть ответственность с больной головы на здоровую.
Бизнес действительно сам идентифицирует какая у него проблема, как правило (все же с низу вверх так же прилетает, другой вопрос слушают/не слушают). Но то что касается неверной идентификации и дальнейших шишек в сторону программистов — это фактически первый кейс который я описал. Если это происходит постоянно, тут вступает в игру Грейд — если я Senior то это повод уволиться (Да, тут зависит конечно от человека). Если Junior, то повод молча проглатывать и нарабатывать больше опыта, потому что я понимаю — чем больше опыта, тем лучше будет следующая компания. А если не брать радикальные методы, можно просто всегда стелить себе соломку — разработчик понимает что проблема идентифицирована не правильно, либо реализация не решит эту проблему => письменно предлагает альтернативы => их не принимают и говорят что лучше знают => начинают лететь шишки, а в ответ отправляется макулатура которую отправляли перед тем как приступить к разработке.
Поправьте меня если я ошибаюсь, но по-моему вы только что предложили НЕ решать проблемы бизнеса :)
Я больше сказал про эффективно/не эффективно. Ты ее в любом случае решаешь. Есть проблема которую идентифицировал бизнес — ты ее решил. Другой вопрос что ты это сделал не эффективно. В статье я про похожее указал — хочешь не хочешь, но решаешь.
Ну, может быть такое, что такое, что выполнив всё, что в задаче сказано, проблему решением которого она заявлена ты так и не решил. Банально, проблема — низкая конверсия, задача — сделать кнопку купить большой, мигающей и всплывающей посреди экрана, да так, чтобы спрятать было сложно. Сделал, да так что единственный способ её закрыть — закрыть вкладку или сломать систему защиты :) Но тут конверсия падает на порядки. Можно ли говорить о решении проблемы?
Давайте для простоты на берегу договоримся что "не эффективно" не связано с техническими скиллами. У нас разработчик сферический в вакууме, который всё знает, всё умеет и багов не допускает. :)
Я вам по сути толкую вот о чём: чтобы эффективно решать проблему бизнеса — надо прежде всего чтобы бразды правления в вопросе опознания самой проблемы и подбора решений были у того, кто проблему решает. Покуда это не так — пытаться решить какую бы то ни было проблему — бесполезное занятие. И я так понимаю, вы с этим согласны.
Что касается предлагать решения — вы знаете, культура везде разная, и в некоторых культурах предложение решения могут прочитать не как попытку помочь, а как попытку выпендриться, попытку протолкнуться по карьерной лестнице, подсидеть начальника и т.п. Так что я бы такое с порога не рекомендовал всё же.
Программист лишь следует полученному ТЗ
Предположим что есть человек который пишет ТЗ, оно к нам прилетает. В нем есть конкретные сроки, но вы понимаете — озвученный функционал не сделать за указаное время (очень частая ситуация). Ваши дальнейшие действия? Просто следовать полученному ТЗ?
Даже если оно неполное, противоречивое или явно (для программиста) не приведёт к достижению и решению обозначенных в нём целей и задач?
То, что в команде нет толковых продукт овнеров со знанием технического стека не проблема разработчика. Зачастую бизнес и сформулироать то не может какие у него проблемы.
Чтобы он по своей инициативе решал несвойственные ему задачи
А почему вы считаете, что написание кода — это несвойственная программисту задача?
А то получается как проблема бизнеса так к программисту бегут, а как делить дивиденты так программисты не причем.
Дивиденты это скорее о вложении своего капитала. И я бы не сказал что программистам запрещено это делать.
А когда к программисту «бегут с проблемами», то ему за это обычно зарплату платят. И зарплата обычно и зависит от того с какими проблемами к нему можно бежать, а с какими нельзя.
Несвойственная задача это решать проблемы бизнеса
То есть вы думаете, что когда программист код пишет, он это делает просто так, а не чтобы решить проблему (или задачу) бизнеса?
Ну вот давайте на примере. Прибегает представитель бизнеса со словами "у меня проблема, с завтрашнего дня налоги надо платить вот так, а не так, как было". Кто эту проблему будет решать? Отряд менеджеров или программист?
как делить дивиденты так программисты не причем
Ну так вообще-то зарплата есть. Которая платится с доходов компании.
Давайте долю чтобы человек чувствовал отдачу от вложения интеллектуального капитала.
Тут ведь дело какое — если "давайте долю", то и вы будьте готовы, что если внезапно отдача от вложения нулевая, то и вам ничего не достанется. То есть встала работа из-за ошибки ПО, несет бизнес убытки — и вы денег не получаете тоже.
Но вообще, участие в прибылях компании, например, в форме акций (или даже привязанной к прибылям премии) вполне себе обыденное явление.
Решать проблемы бизнеса не его KPI.
В каждой компании они свои, если вообще есть. В одной их тех, где я работал в процессе пересмотра зарплаты/позиции даже отдельный процесс был: опросить заказчиков задач, которые решал программист за период и попросить оценить его по нескольким параметрам включая степень вовлеченности именно в бизнес-задачи. И вес у этого фактора был весьма заметный
Программист пишет код в рамках своих должностных обязанностей, в зоне своей ответственности.
Так это никак не противоречит решению бизнес-задач. Его должностные обязанности, собственно, направлены на решение бизнес-задач, потому что иначе зачем он нужен? Или вам надо, чтобы в должностной инструкции вместо "написание программ" было "написание программ для решения бизнес-задач"? Так суть-то не изменится.
Как то не очень получается, что человек, решающий проблемы компании делает это не за долю.
Да нет, нормально получается. Или сотрудник службы поддержки, вся работа которого состоит в том, чтобы решать чьи-то проблемы, тоже должен делать за долю (от чего, кстати)?
Не, можно и за долю, не вопрос. Только когда проблем/задач нет, доли тоже не будет. Или, что веселее, когда два месяца пилили, а оно проблему не решило — значит, пилили бесплатно. Хорошо?
И если к нему прибегают что «с завтрашнего дня налоги по-другому» это простите некудышний менеджер/бухгалтер, обычно это планируют, а не закрывают переработками разработчика и мантрой про необходимость решать проблемы бизнеса.
Ну давайте заменим "завтра" на "через год". Все равно это проблема для бизнеса. Кто ее решать будет? Отряд менеджеров или программист?
(А переработки и другие следствия "никудышного менеджмента" решаются оплатой переработок по ТК.)
Вы путаете "проблемы бизнеса" с формализацией трудовых задач для работника. Работник не предполагает работать плохо, но не стоит втягивать его в управленческие вопросы без его согласия и соотв.компенсации. и эта компенсация как и обязанности в дополнение, а не вместо обычных. А когда проблем/задач нет это значит, что они качественно решены и следовательно доля(в сумме) должна вырасти, а не отмениться, вы ж партнеры уже, что за кидок ?!)
Вы путаете "проблемы бизнеса" с формализацией трудовых задач для работника.
С чего вы это взяли?
но не стоит втягивать его в управленческие вопросы без его согласия и соотв.компенсации
Подождите, а откуда взялись "управленческие вопросы"? Я говорил о проблемах/задачах бизнеса, а не об управленческих вопросах.
А когда проблем/задач нет это значит, что они качественно решены и следовательно доля(в сумме) должна вырасти, а не отмениться, вы ж партнеры уже, что за кидок
За что доля-то, если не делаешь ничего?
«Проблемы бизнеса» это всегда управленческие проблемы
Из какого формального общепринятого определения вы это взяли?
Лично для меня "проблемы бизнеса" — это все, что мешает бизнесу функционировать. Нехватка товара на складе — проблема бизнеса. Выключилось электричество в датацентре — проблема бизнеса.
Прибегает представитель бизнеса со словами «у меня проблема, с завтрашнего дня налоги надо платить вот так, а не так, как было»
ну хз, программист должен иметь экспертизу в бухучете, я правильно понял?
Не, можно и за долю, не вопрос. Только когда проблем/задач нет, доли тоже не будет. Или, что веселее, когда два месяца пилили, а оно проблему не решило — значит, пилили бесплатно. Хорошо?
в стартапах порой берут в долю. И может кому-то такое и подходит, почему бы и нет?
Есть 2 варианта:
1) исполнитель в доле. Тогда он решает проблемы бизнеса, и делит как успехи так и поражения.
2) исполнитель — просто исполнитель, он превращает требования в код. В таком случае он не обязан решать проблемы бизнеса. Уточнить требования у BA — ок, но это всё.
Вы же по сути хотите чтобы программист получал ставку из варианта 2) но при этом выполнял работу из варианта 1)
это двоемыслие, типа «возьмите себе обязанности без бенефитов».
ну хз, программист должен иметь экспертизу в бухучете, я правильно понял?
Нет, не должен. Зачем?
В таком случае он не обязан решать проблемы бизнеса.
Он обязан, в доступном ему объеме, решать поставленные ему задачи. Нет?
Ну вот смотрите, в программе, которой бизнес пользуется в критическом процессе, обнаружилась ошибка. Для бизнеса это проблема, работать нельзя. Кто будет решать эту проблему?
Вы же по сути хотите чтобы программист получал ставку из варианта 2) но при этом выполнял работу из варианта 1)
Я? Нет, не хочу.
Он решает проблему бизнеса своим посильным вкладом.
Ну так я вроде это и говорю.
Он обязан, в доступном ему объеме, решать поставленные ему задачи. Нет?
вот что мне нравится, так это железобетонная уверенность кто, что и кому обязан ))
программист получает требования и пишет код. Или вносит исправления. В рамках компетенции и поверхностных представлений о предметной области может вносить уточняющие вопросы, прояснять требования, может быть даже вносить предложения. Окей, это считается что он выполняет то что обязан?
«решать проблемы бизнеса» — очень расплывчатая формулировка. Сюда можно просунуть что-угодно. И это ведь выгодно, ага, давай ты будешь и бизнес-аналитиком, и девопсом, и саппортом — и всё на одну зарплату, как же.
Это эдакий хитрый вариант демагогии и манипулирования: типы мы, корпорации, будем придумывать критерии а ты превозмогай и соответствуй, иначе «ты — не настоящий программист».
И это ведь выгодно, ага, давай ты будешь и бизнес-аналитиком, и девопсом, и саппортом — и всё на одну зарплату, как же.
Точно ли это выгодно бизнесу получить за 1 сеньорскую зарплату, 0.25 сеньор-разработчика, 0.25 БА, 0.25 БА и 0.25 саппорта? Последних хорошо если миддлового уровня.
вот что мне нравится, так это железобетонная уверенность кто, что и кому обязан
Ну должны же быть какие-то ожидания от людей, которые работают на найме, правда? И обязательства у них есть, хотя бы те, которые закреплены в должностной инструкции. Разве не так? Или у вас наемный работник не имеет обязательств?
Окей, это считается что он выполняет то что обязан?
Да, считается.
«решать проблемы бизнеса» — очень расплывчатая формулировка.
Ну так никогда не возбраняется задать уточняющий вопрос.
Сюда можно просунуть что-угодно.
Если везде видеть злой умысел, то почти куда угодно можно просунуть что угодно.
И это ведь выгодно, ага, давай ты будешь и бизнес-аналитиком, и девопсом, и саппортом — и всё на одну зарплату, как же.
… не, не выгодно. Потому что всё плохо.
Это эдакий хитрый вариант демагогии и манипулирования: типы мы, корпорации, будем придумывать критерии а ты превозмогай и соответствуй, иначе «ты — не настоящий программист».
Это эдакий хитрый вариант демагогии и манипулирования — типа, мы, программисты, будем придумывать критерии, а ты превозмогай и соответствуй, а иначе — ты плохая корпорация.
Чесслово, если корпорация плохая, дело будет совсем не в "решении проблем бизнеса". А если хорошая, то и проблемы будут интересные.
Это эдакий хитрый вариант демагогии и манипулирования — типа, мы, программисты, будем придумывать критерии, а ты превозмогай и соответствуй, а иначе — ты плохая корпорация.
я не манипулирую, скорее защищаюсь, в данном случае от навешивания задач произвольного характера с формулировкой «ты обязан решать задачи бизнеса».
Ну должны же быть какие-то ожидания от людей
есть большая разница между «какие-то» и «те которые уместные». Программист — программирует, врач — лечит, адвокат — защищает. Работа программиста не является законченным продуктом, он зависит от множества людей, он всего лишь один из участников конвеера.
в данном случае от навешивания задач произвольного характера с формулировкой «ты обязан решать задачи бизнеса».
Понимаете ли, от навешивания задач произвольного характера надо защищаться безотносительно формулировок. И приставать к конкретной формулировке весьма странно, особенно учитывая, что формулировка-то, на самом деле, по делу.
есть большая разница между «какие-то» и «те которые уместные».
Я как-то привык думать, что ожидания "решать задачи в рамках позиции и компетенции" — это разумные ожидания.
Работа программиста не является законченным продуктом
Я, вроде, обратного нигде и не говорил.
Чесслово, если корпорация плохая
мы говорим о коммерческих организациях. Если бы они могли, они бы платили ноль своим сотрудникам. Я даже не уверен что тут применимы слова «хороший» или «плохой». Это за гранью этих понятий. Я бы разве что употребил как максимум «приемлимый»
Если бы они могли, они бы платили ноль своим сотрудникам.
Неа. Я как-то присутствовал при ситуации, когда некий человек предлагал работать "за опыт", то есть бесплатно, но начальство сказало, что будем платить деньги.
мы говорим о коммерческих организациях.
Знаете, коммерческими организациями управляют люди, работают в них люди и решения принимаю люди. А людям, как ни странно, свойственна эмпатия.
Сколько бы и кто не говорил что компании — это не зло, там просто люди и тд, — интересы компании и наёмного работника на ставке прямо противоположны друг другу. Компания живёт за счет прибавочной стоимости, т.е. за счет того что часть забирает себе. Оставим за скобками что это справедливо/несправедливо — это просто факт. Отделы HR в компаниях, всякие «пипл партнеры» созданы не с целью развития, а с целью удержания зарплат. И это специально обученные люди, которые естественно прежде всего подкованы в ведении переговоров. Т.е. компания тратит часть средств на создание видимости заботы о сотрудниках. Естественно, купить теннисный стол в офис куда дешевле чем поднять заплату всем сотрудникам на уровень выше рыночного.
То что вы видели такой случай — это хорошо. Но ведь много и других случаев, и один этот — ничего не доказывает.
в общем, не согласен с Вами )
Почти любая особь стремится увеличить свою власть, прибыли, делая при этом как можно меньше.
Я бы сказал, что это утверждение субъективно и недоказуемо. А вы из него делаете все дальнейшие выводы.
Я бы сказал, что это утверждение субъективно и недоказуемо.
это утверждение точно так же недоказуемо и точно так же субъективно ))
А ваши выводы на чем основаны?
Какие конкретно?
это утверждение точно так же недоказуемо и точно так же субъективно
Ну да, оно прямо начинается с "я бы сказал".
биология это не прям точная наука
Биология тут ни при чем. Вы оперируете в рамках социологии.
Какое тут может быть доказательство, прям формулами, что ли?
Я и говорю: недоказуемо.
Могу иначе сформулировать, если хотите: ненаучно, потому что не проходит критерий Поппера.
могли бы хоть сказать, почему именно вы считаете это неправильным.
Потому что это противоречит моему жизненному опыту.
Вывод основан на том что есть прибавочная стоимость. И в интересах компании иметь как можно большую разницу между тем что работник производит и его зарплатой. Ок, ненаучно, это просто логические размышления. В чем тут ошибка?
сам факт ненаучности не делает мой вывод неверным. Если есть конкретный мысли (пусть и из жизненного опыта) — ну так напишите.
Тезис «твои вывод — говно» — тоже ничего не доказывает и не опровергает.
ну и какой смысл тогда том замечании что это ненаучно? Что с того что ненаучно?
Поскольку это ненаучно, я не знаю никакого способа проверить ваше утверждение. А это, в свою очередь, означает, что сделанные из него выводы — это некое умозрительное построение, которое верно только при допущении, что ваше исходное утверждение верно. А поскольку я не согласен с тем, что ваше исходное утверждение верно, сделанные из него выводы для меня ложны.
И в интересах компании иметь как можно большую разницу между тем что работник производит и его зарплатой. [...] В чем тут ошибка?
В предположении, что единственный интерес компании — это максимизация выгоды.
Право же, зачем занудствовать? И так ясно что это умозрительные построения. Но как я и сказал, это не делает что-либо неверным само по себе. Мы не на диспуте, я просто беседую.
так что не так с максимизацией выгоды?
так и не озвучиваете в чем заключается ваша позиция.
Да я вроде ее уже озвучил неоднократно. В данном конкретном случае она сводится к тому, что у людей и, как следствие, компаний, есть другие интересы, кроме максимизации денежной выгоды.
Даже если предположить что основатель — и правда человек который во что-то верит (почему нет?). Есть инвесторы, а они уж точно вряд ли альтруисты. Весь бизнес так устроен что альтруизму там места нет почти всегда.
конечно есть. Но деньги — главный стимул.
Так вот, если есть другие стимулы, помимо главного, они могут этот "главный" перевешивать и подменять. Что означает, что компании могут действовать не только в интересах максимизации денежной выгоды. Что, в свою очередь, означает, что компания вполне может заботиться о своих сотрудниках, а не имитировать эту заботу.
могли бы хоть сказать, почему именно вы считаете это неправильным.
Люди назначаются на должности из знакомых и по связям.
Один из плюсов — ты знаешь этих людей лучше, чем незнакомых. Знаешь некие пределы надёжности, доверяешь им больше(кому доверяешь).
Максимизировать прибыль можно и увеличивая доход с одного работника, а не уменьшая расходы на него. И, кстати, "сеньор должен решать бизнес-проблемы" один из способ увеличения дохода с сеньора. И компании может быть выгодно реально заботиться о сотрудниках хотя бы чтобы потом не тратиться на онбординг нового.
И, кстати, "сеньор должен решать бизнес-проблемы" один из способ увеличения дохода с сеньора.
Без пропорционального увеличения дохода сеньора.
Как договоришься, чай не в СССР живём со всесоюзными тарифными сетками, и то как-то специалистов сманивали.
И в целом мне не жалко, если нравится работать. Что с того, что договариваясь со мной на N денег, они рассчитывали получить с меня kN дохода, где k > 1, а по факту я, не ограничиваясь написанием кода, приношу им (k+p)N? p*N они со мной делить не обязаны, если не было на то договоренности "на берегу"?
Почему дарить? Я договорился работать на него 40 часов в неделю и получать N денег. Работаю — получаю. Где тут что я дарил?
Более того, когда договариваюсь, то я предполагаю, что я буду вникать в бизнес, решать бизнес-задачи и проблемы, а не код по спецификациям писать. То есть даже нельзя сказать, что я вдруг, уже после того как договорился, узнал, что я намного эффективней чем рассчитывал, чтоб требовать прибавки.
Что я рассчитывал делать за N денег, то и делаю. Если вдруг окажется, что в другом месте за тоже самое мне предлагают больше, тогда и подумаю попросить прибавки или перейти.
А не знаю. Галеры стремятся максимально унифицировать процессы
это значит увеличение разницы между тем что работник приносит и сколько он получает из этого. :)
это то что я и говорил.
И компании может быть выгодно реально заботиться о сотрудниках хотя бы чтобы потом не тратиться на онбординг нового.
это не доброта и не забота, а расчет. И эта модель, в основе которой лежит расчет, будет заботиться о сотруднике ровно настолько, чтобы поддерживать нужный баланс кадров (количество ушедших против количества пришедших)
Поскай не обязан, но добровольно-то может?
Бизнесу важен результат.
Вот здесь источник очень многих последующих ошибок.
Во первых не бывает никакого монолитного целостного бизнеса, которому нужно что то одно и все. (что бы сам «бизнес» про это не говорил на совещаниях вместе с руководством). Это совокупность многих хитроопых людей со своими взаимоисключающими желаниями. Притом зачастую взаимоисключающими в рамках даже одной руководящей или исполнительной личности. К примеру «решают проблемы бизнеса» переводя задачи в субподряд собственной не самой эффективной организации, но своей.
И вот если рассматривать «бизнес» как совокупность всех интересов всей совокупности участников, то оказывается, что доступен огромный спектр поведения, которое будет отвечать каким либо интересам этих участников и не отвечать интересам других. Поможешь одному — копнешь под другого.
Отсюда вывод «решение проблем бизнеса» — идиома, не имеющая под собой конкретики и может быть наполнена очень вариативно в зависимости от интересов людей, ее наполняющих.
1. финансовую
2. смысловую
А бизнес должен ему в этом помочь, предоставив 1. хорошо оплачиваемую и 2. интересную работу. Там могут быть разные пропорции между оплачиваемостью и интересностью, в зависимости от которых программист на собеседовании (или немного после) решает, подходит ли ему работодатель.
Но бизнес предоставляет это ему, чтобы он эффективно решал его, бизнеса, проблемы. win-win должно быть. Но есть один нюанс: и программисты, и бизнесы неоднородны. Одному программисту хочется решать непосредственно бизнес-проблемы, будучи свободным в выборе технических, а может и не только, средств решения (в разумных, конечно, пределах), а другому получать чёткие спецификации и делать минимально необходимую работу для прохождения приемочных критериев. Одному бизнесу нужен первый, а другому второй. Нужно просто найти друг друга.
Я знаю один проект (в последние года полтора он в агонии). Там придерживались с самого начала того мнения, что работник должен слепо исполнять хотелки бизнеса. И так вот и было долгое время. Хотелка за хотелкой, фича за фичей. Без какого-то плана действий. Рефакторинг? Не, это бизнесу не нужно. В итоге куча дублирующего функционала, неизвестных никому фич (кто заказал и кто исполнял уже не работают в компании). Документации ноль (а зачем, клиент же это не видит, а новые акции надо еще вчера запускать). Привело это к тому, что в коде к определенному моменту не ориентировался никто. Какие-то новые фичи делать уже никто не мог (ибо хрен знает, как там все связано, и что это поломает). А почему? А потому что программистов никто не слушал с их пожеланиями к ведению разработки. А так как проект уже в агонии (из-за опять же менеджмента), то ресурсов на рефакторинг/переписывание чего-то с нуля уже нет. Занимаются тушением пожаров и оптимизацией кадров. Программистов на фултайм там уже нет...
Есть, например, скрам со стори покером, где оценку на хотелки дают не то, что не тимлиды, а даже джуны. И к ним ко всем идёт менеджер, ПО с просьбой оценить задачи.
Не всегда. Это может быть принципиальная политика компании типа плоская структура и т. п. или "так исторически сложилось". Или просто этот сеньор лучше всех в фирме разбирается в разработке вообще и архитектуре существующей системы в частности, и даже при наличии формального лида, бизнес сам идёт к нему с хотелками на проработку и уже готовую задачу направляет на лида, чтобы соблюстси формальные процессы
Или лид есть, он занимается планированием, мотивацией, распределением задач и прочими управленческими процессами, сам к коду и архитектуре не прикасаясь. Ну или, например, CI/CD настраивая по старой памяти.
Лид — сам менеджер, особенно такой. А за что он отвечает решает каждая компания, а то и отдельные её подразделения, самостоятельно, так как она считает, что ей будет выгодней. решили компания чтоб хотя бы одна команда поработал по скраму — а нет там роли лида, не предусмотрена: владелец продукта, скрам-мастер, и команда разработчиков.
и в рукаве которого обычно припасены пару козырей для решения нетривиальных проблем
Вот, даже не бизнес-задачи может решать, а сразу проблемы.
И в правду, зачем тратится на QA, DevOps, BA, TL, CTO, PM, если можно взять одного «сеньйора»? А лучше Full-stack, который действительно за ИТ одел должен пахать :)
Работать «сеньйор» всё равно 40 часов в неделю будет, действительно ли это дешевле выйдет? Не знаю сколько BA получают, но навскидку «сеньйор» дороже всех остальных кроме TL и CTO, и то могут быть нюансы.
Не знаю сколько BA получают
Судя по контексту, это те чуваки, которые в команде требования пишут (я просто уточняю, потому что под BA люди разное понимают), и эти, по моим наблюдениям, тоже получают меньше senior.
Тогда вообще непонятен хитрый замысел злого бизнеса по вынуждению сеньоров выполнять обязанности менее оплачиваемых специалистов.
Проблема только в том что во первых их и так не особо много, во вторых они обычно «завязаны» на свои отрасли и в третьих на мой взгляд среди них плохих гораздо больше чем хороших.
Поэтому часто их место занимают менеджеры/инженеры/программисты с хорошими знанием/пониманием смежных областей…
Злой бизнес не всегда умный бизнес, что правда, то правда. Но обычно если такой замысел есть, то он от тупой нехватки ресурсов (и их неправильного распределения). И хорошо это заканчивается редко.
Ну вот нас убеждают, что все эти "программист должен решать бизнес-задачи" — манипулирование программистами с целью заставить их (нас) выполнять не свойственными программистам функции за те же деньги (некоторые вон за это ещё и долю в прибыли хотят). А вот мне как-то расклад не понятен.
мне как-то расклад не понятен
не страшно )
ну если хочется вам выполнять бизнес-задачи — ваш выбор, выполняйте, никто же не запрещает )
но к чему пытаться навязать эту парадигму как непременно правильную всем остальным?
Сообщество (кто не хочет) противится так как чует в этом подвох. Ну не хотят и черт с ним. В чем проблема-то?
А я и не пытаюсь, я пытаюсь чтобы не навязывали противоположную, "сеньору запрещено решать бизнес-проблемы не путём написания кода", парадигму как непременно правильную. И не говорите, что такого не бывает, вон в комментах уже отметились представители бизнеса с регламентами, процессами и ролями.
В целом ощущение, что среди противников "сеньор должен" немало тех, кто не хочет решать проблемы бизнеса, но понимает, что если его коллега будет решать, а он не будет, то повысят зп и/или позицию коллеге, не смотря на то, что технически он может и слабее.
кстати, это не так уж и очевидно ) Ошибка некомпетентного человека может дорого стоить.
UPD. Забавно, буквально выше вы говорили что вам не жалко если работодатель даст вам в разы ниже чем вы ему приносите, но вас заботит чтоб коллеги не косились что вы технически кого-то слабее, а получаете больше…
Нет, не так. Я защищаю своё право работать в среде, где все решают проблемы бизнеса, ну а получают как решают :)
Ошибка некомпетентного человека может дорого стоить.
Компетентные люди тоже ошибаются. И их ошибки иногда обходятся очень дорого.
Что, возможно, меньшая техническая компетентность не является препятствием для того, чтобы приносить пользу.
Но причем тут ошибки более компетентных?
А при чем были ошибки некомпетентных в вашем комментарии?
Я всего лишь предоставил контекст к вашему утверждению.
Из того что более компетентные ошибаются, никак не следует полезность менее компетентных автоматически. Эти два понятия не связаны.
Отнюдь, они связаны. Из того, что более компетентные тоже ошибаются, становится понятно, что то, что менее компетентные ошибаются, еще не делает их непригодными для работы.
Отнюдь, они связаны.
я не согласен, и спорить по этому поводу не хочу. Недостатки или промахи одних не делают других лучше. Этот топик начался с того что якобы есть люди, которые технически слабее, но платить им надо больше — т.к. они «решают проблемы бизнеса».
у ошибок есть стоимость, да. То что ошибки компетентных стоят больше — это просто голословное заявление. Где доказательства?
Я вижу вам нравится поспорить, но я останусь при своём мнении в любом случае :)
Недостатки или промахи одних не делают других лучше.
А я и не говорил, что кто-то становится лучше.
Этот топик начался с того что якобы есть люди, которые технически слабее, но платить им надо больше — т.к. они «решают проблемы бизнеса».
Есть, конечно. Менеджер на несколько уровней выше разработчика в пищевой цепочке, скорее всего, технически слабее оного разработчика, но денег получает больше. А уж если вы дойдете до верха...
Или другой пример: одно дело, когда для того, чтобы выполнить задачу, нужно заплатить разработчику + постановщику задачи, а другое дело, когда только разработчику, потому что он способен взять на себя функции постановщика задачи тоже. Этому второму осмысленно платить больше, потому что это все равно меньше, чем платить двум людям в первом случае.
Правда, это все не имеет никакого отношения к "проблемам бизнеса", потому что, как я неоднократно говорил, проблемы бизнеса решают почти все. Это имеет отношение к тому, что есть люди, которые занимаются только и исключительно разработкой, а есть люди, которые берут на себя и другие задачи тоже.
Есть, конечно. Менеджер
нее, менеджеры это отдельная тема. Я говорил о программистах.
Это имеет отношение к тому, что есть люди, которые занимаются только и исключительно разработкой, а есть люди, которые берут на себя и другие задачи тоже.
вот я и говорю — нужны оба этих типажа. Если все станут «технически послабее» но будут «решать проблемы бизнеса» — это будет лучше? Сомневаюсь. Кто-то должен строить тех. системы и делать это грамотно. В этом процессе много всего, да. И собрать требования, и понято что нужно, атрибуты качества, собрать команду и тд. Но давайте просто предположим что все эти этапы пройдены, и нужно в конце концов сделать систему — спроектировать архитектуру, живучую, и потом дать её сделать. Допустим стоит задача — сделать соц. сеть типа LinkedIn на много миллионов юзеров. Чтобы это сделать — нужно в этом разбираться. Т.к. нельзя бесконечно бежать и прятаться за доводами «не только tech важен», т.к. в конце концов придётся делать и его тоже.
Если все станут «технически послабее» но будут «решать проблемы бизнеса» — это будет лучше?
А все не станут. Потому что это набор навыков, который не всем доступен.
Кто-то должен строить тех. системы и делать это грамотно.
А почему вы думаете, что люди "технически послабее" не умеют строить системы грамотно?
Но что еще важнее, хороший специалист (мы же говорим о том, что человек слабее технически, а не что он плохой специалист, правда?) знает свои границы. И не боиться обратиться за консультацией или и вовсе перепоручить работу.
А почему вы думаете, что люди «технически послабее» не умеют строить системы грамотно?
так можно методом по индукции прийти к тому что никому ничего знать не надо. У «грамотно» есть степень. Есть грамотно написать REST api, а есть грамотно построить Линкедин.
ещё раз — никто не говорит что менее компетентные люди — это плохо. Но из этого никак не следует что они могут всё, а если не могут — то и не надо. Все не могут перепоручить работу друг другу, кому-то придётся сделать.
Не было "надо платить больше". Было что-то вроде: "им могут платить больше"
Компьютерная безопасность. Там тоже можно «решать проблемы» бизнеса, будучи технически слабым в самой безопасности? Всё стоит на том что за спинами тех кто ещё не набрался опыта, стоят те кто уже опытны. Да, они ошибаются, потому что на них больше ответственность, но это не значит что замени их на менее компетентных — и вуаля, стало лучше. Это чушь и фантазии. Никто не пытается унизить какие-то категории специалистов, скорее наоборот
разве уже мало примеров чего стоила некомпетентность?
Проблема этих примеров в том, что мы, чаще всего, не знаем, что будет, если бы там были более компетентные люди.
Вот история с боингом.
Кстати, а чья конкретно некомпетентность виновата в истории с боингом? "Airbus, its main competitor, is unwilling to put the blame on Boeing's engineering".
Там тоже можно «решать проблемы» бизнеса, будучи технически слабым в самой безопасности?
А зачем вы подменяете менее компетентных на некомпетентных? Есть такая штука, как достаточный уровень компетенции для решения задачи.
Да, они ошибаются, потому что на них больше ответственность, но это не значит что замени их на менее компетентных — и вуаля, стало лучше. Это чушь и фантазии.
Да, фантазии. Только это… ваши фантазии, потому что никто из ваших оппонентов такого не предлагал.
Кстати, а чья конкретно некомпетентность виновата в истории с боингом? «Airbus, its main competitor, is unwilling to put the blame on Boeing's engineering».
приняли решения, выгодные только краткосрочно, в погоне за прибылью.
Проблема этих примеров в том, что мы, чаще всего, не знаем, что будет, если бы там были более компетентные люди.
ну не знаю. Всегда есть возможность доверить делать менее компетентным. У вас в профайле написано что вы архитектор. Можете проверить сами.
приняли решения, выгодные только краткосрочно, в погоне за прибылью.
Кто принял?
Всегда есть возможность доверить делать менее компетентным.
Регулярно получается достаточно хорошо, чтобы выпускать в продакшн.
У вас в профайле написано что вы архитектор. Можете проверить сами.
Ну, я проверял. "Более компетентные" регулярно допускают совершенно идиотские ошибки, иногда долетающие до прода и радостно его хоронящие.
Ну, я проверял. «Более компетентные» регулярно допускают совершенно идиотские ошибки, иногда долетающие до прода и радостно его хоронящие.
ну если они более компетентные в кавычках то конечно.
что вы там намеряли лично — это хз. Может эти люди позиционировали себя экспертами, а на деле ими не являлись. Может вы ожидали что раз они эксперты, то они обладают божественной силой.
Тем не менее, что-то ни Гугл, ни Майкрософт не стремится нанимать менее компетентных вместо более. А они не очередной попсовый дейтинг, и сомневаюсь что там все дураки.
Что кто-то там ронял прод, это мало о чем мне говорит.
Тут ничего не понятно, с этими замерами что более компетентные — это фигня, лучше брать менее. Может просто это стратегия компании — экономия на специалистах. И кто там как и что замерял, как интерпретировал результаты и тд — всё это один большой вопрос.
P.S. судя по тому как вы отписываетесь по всей ветке и спорите со всеми — думаю вам просто нравится спорить, и предмет спора имеет второстепенное значение, главное процесс
что вы там намеряли лично — это хз.
Ну то есть сначала вы говорите "Можете проверить сами", а потом говорите "что вы там намеряли лично — это хз". SRSLY?
Тут ничего не понятно, с этими замерами что более компетентные — это фигня, лучше брать менее.
Мне тоже не понятно, где вы берете такие замеры.
Мне тоже не понятно, где вы берете такие замеры.
я бы вас попросил — это утомительно и неприятный стайл общения, когда собеседник лишь дёргает фразы, и применяет по кругу трюки типа «я этого не говорил» (вместо того чтобы обозначить свою позицию) или «так я уже говорил», «это ниоткуда не следует», «с чего вы взяли?», «где я такое сказал?», «вывод неправильный», «где доказательсва», «это ненаучно» и тд., по максимуму докапываясь до слов собеседника, и поменьше донося свою позицию (разумеется, цель ведь не в этом, в конце концов). Это похоже на демагогию. Если вы по-другому не можете, то я, пожалуй, не буду дальше обсуждать.
вы снова занимаетесь метааргументацией, вместо того чтобы обозначить свою позицию.
Так я же ее обозначил несколькими комментами выше: "меньшая техническая компетентность не является препятствием для того, чтобы приносить пользу" и "[у менее компетентных] регулярно получается достаточно хорошо, чтобы выпускать в продакшн."
это утомительно и неприятный стайл общения
"Утомительно и неприятно", когда собеседник постоянно приписывает тебе позицию, которую ты не озвучивал и не поддерживаешь.
Так я же ее обозначил несколькими комментами выше: «меньшая техническая компетентность не является препятствием для того, чтобы приносить пользу» и "[у менее компетентных] регулярно получается достаточно хорошо, чтобы выпускать в продакшн."
«я же уже говорил»
«Утомительно и неприятно», когда собеседник постоянно приписывает тебе позицию, которую ты не озвучивал и не поддерживаешь.
«ты понял неправильно». Приём — «отрази на собеседника его обвинение» (которое просьба)
и так всё время.
хорошего дня :)
В обязанности программиста не входит требования «понимание бизнеса». Если ваш программист начал что-то там про бизнес-вижин толкать, стоит гнать его поганой тряпкой. Он не программист, а болтун на чужом месте.
Для ведения проекта уже десятилетиями выработана вполне устойчивая структура, которая обкатана на миллионах проектах, решаюших львиную часть проблем. Но вот как только начинается «оптимизация» по зарплате и затратам на «не приносящие прибыль отделы», так и всплывает пресловутое «должен».
Должен бизнес-аналитик. И техлид, который описанные аналитиком проблемы переводит в четко специфицированное техническое задание. А обязанность программиста — оценить ТЗ, выявить возможные нестыковки (если что не понимает), после чего реализовать код чисто, с максимальной производительностью и покрытием тестами.
Ну, а если вам кто-то из руководства начинает рассказывать про понимание бизнес-процессов, а вы не имеете пресловутых лычек бизнес-аналитика или техлида, то можно смело искать другую работу. Потому что первый звоночек уже прозвенел.
Если человек несет риски, он имеет право на часть дохода.
Если человек не несет риски, то его не волнуют ваши( а они именно ваши, он в вашем бизнесе наемный сотрудник и к вашему бизнесу никакого отношения не имеет ) проблемы( это не его риски ), он имеет право на оклад и защищен трудовым правом, но не имеет отношения к разделению прибыли.
Вот собственно говоря и все. Хотите делить риски делите компанию/прибыль.
У наёмного сотрудника тоже есть риски типа увольнения из-за банкротства или принятия неудачного решения в пределах своих "дефолтных" должностных обязанностей.
С другой стороны, не все в принципе претендуют на часть дохода выше оклада, решая, добровольно или принудительно, с интересом или "кроме меня некому — придётся возиться", инициируя создание рабочих задач или приходя с готовым решением, известные ему проблемы бизнеса.
Я лично всегда придерживался первого варианта, просто потому, что программист, зная внутренние детали, иногда может предложить вариант, о котором начальство просто не подозревает, или думает, что это слишком сложно. Но опять же это все добровольно и во многом зависит от отношений внутри коллектива. Зачем пытаться все формализовать и загнать всех в одни рамки?
Программист должен делать то, что указано в его рабочих обязанностях.
Я вот заинтересовался на фоне этой беседы, да. Нашел какую-то должностную инструкцию программиста, а там смешное:
2.1.15. Обеспечивает правильную техническую эксплуатацию, бесперебойную работу компьютеров и отдельных устройств.
2.1.16. Участвует в разработке перспективных и годовых планов и графиков работы, технического обслуживания и ремонта оборудования, мероприятий по улучшению его эксплуатации, предупреждению простоев в работе, повышению качества работы, эффективному использованию вычислительной техники.
2.1.17. Осуществляет подготовку компьютеров и отдельных устройств к работе, их технический осмотр, проводит проверку наличия неисправностей, устраняет неисправности и предотвращает появление неисправностей в будущем.
2.1.18. Принимает меры по своевременному и качественному выполнению ремонта компьютеров и отдельных устройств своими силами или силами третьих лиц.
2.1.19. Принимает участие в проведении инвентаризаций.
[...]
2.1.23. Исполняет распоряжения и приказы Генерального директора предприятия и руководителя отдела IT.
2.1.24. Информирует руководство об имеющихся недостатках в работе предприятия, принимаемых мерах по их ликвидации.
2.1.25. Способствует созданию благоприятного делового и морального климата на предприятии.
Прямо обхохочешься.
чтобы отдельно взятый программист был максимально эффективен
Тут ещё важно понимать в чём для бизнеса измеряется эффективность программиста.
Решение проблем бизнеса — это довольно очевидный критерий эффективности, который просто явный и лежит на поверхности. Но по такому критерию кто-либо, влияющий на результат лишь косвенно — бесполезен, т.к. его работа «неочевидна» и имеет влияние лишь через n-ое звено цепочки.
Если программист законтрибютал много в опернсорс, может там линукса или кубернетеса — он решал какую-то проблему бизнеса? НЕТ. Но его решения опосредованно, косвенно решают проблему бизнеса.
Дональд Кнут решал проблемы бизнеса? Тоже нет. Так что, все эти люди, стало быть, неэффективны?
Ошиблись. Я хочу, чтобы бизнес озвучивал свои критерии моей эффективности при обсуждении условий сотрудничества. А там я уже буду решать подходят они мне или нет.
Решение проблем бизнеса — это довольно очевидный критерий эффективности, который просто явный и лежит на поверхности.
Кстати, нет, потому что его очень сложно посчитать для любого случая, который не начинается с запроса о поддержке.
И сразу возникает весь спектр вариантов ответа. От альтруизма и всеобщей любви, до войны всех против всех. Как и всегда, истина прячется где-то посредине, в балансе кооперации и конкуренции, поскольку и первое, и второе — основа нормальных экономических взаимоотношений.
В какой-то мере мы все друг другу помогаем. Но интересы клиента и
Гипотетически можно предположить формат общества «монолитных интересов» и «чистой кооперации», где совокупные потребляемые блага делятся абсолютно поровну, и в принятии любых решений принимают участие абсолютно все люди с равным правом вето, но, похоже, состоится этот «коммунизм» не скоро…
Программист должен решать проблемы бизнеса