Как стать автором
Обновить

Комментарии 119

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

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


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


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

А мне пришлось поработать программистом, а потом средним звеном между саппортом (т.е. решал проблемы пользователей, которые не могли быть исправлены саппортом) и командой разработчиков (у меня были задачи для добавления нового функционала, но 60-70% времени я тратил на разгребание проблем юзеров). Компания была стандартной «галерой», но команда в которой я работал была «продуктовой», т.к. работала над одним и тем-же продуктом с начала его разработки.

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

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

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

А еще, когда разработчик предлагает «простое» и «advanced» решение проблемы, часто «advanced» продиктовано личным опытом: всё это он уже проходил на другом проекте\в другой компании и знает, что после этой кнопочки нужно будет ещё 3, которые чуть-чуть отличаются, но чтоб их добавить «потом», нужно будет с нуля переписать самую первую\простую.
Поддержка и медленное усовершенствование — это как раз те области в жизненном цикле продукта, где технический долг особенно сказывается. На этапе разработки и ввода в эксплуатацию можно на многое забить, лишь бы успеть запустить как можно раньше, но надо сознавать к чему это приведёт в дальнейшем.
Как бы странно это не выглядело, но руководящий состав все больше становится заложниками в этой игре интересов.
Давайте рассмотрим типичную ситуацию. Есть несколько категорий работников:
1. Есть программист, который получает неплохие деньги и который кипит идеями.
2. Есть руководство (менеджер/директор) который ставит ему задачи и платит деньги из бюджета проекта.
3. Есть продажник, который занят продажей продукта. Ему без разницы как работает кнопочка, ему сам факт ее наличия делает продажи.
4. Есть заказчик/покупатель, который платит денежку за продукт, из которой формируется бюджет.

Теперь вспомним, что зарплата программиста (1.) растет регулярно (он же прокачивается, да и вообще рынок тут растет). Он начинает выламывать руки руководителям (2.) для проталкивания правильных идей, однако он не представляет потребности потребителя (4.).
Продажник (3.) примерно представляет, как та или иная функциональность повлияет на воронку продаж (а значит и на прибыль). Т.е. нужда потребителя (4.) ему сильно ближе. Однако все мы знаем, что на рынке продажников (3.) особого роста нет из-за нереально высокой конкуренции. Поэтому, он либо не доносит вообще эту информацию до руководителя (2.), либо делает это максимально аккуратно, чтобы не потерять место.
В результате руководитель (2.) опять требует от программистов (1.) не полета фантазии, а реализации конкретики, которую он смог понять от продажника (3.) и заказчика (4.). И это реально важно, т.к. он видит, что в противном случае бюджета на зарплату программиста (1.) не хватит.
Система переходит из состояния покоя в маятник, когда руководители пытаются найти баланс между бюджетом, генерируемым продажником (3.) и потребителем (4.) с одной стороны и потребностями программиста (1.) с другой. Отсюда и нарастание технического долга, и неудовлетворенность.

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

Второй момент, это комментарий, который приводит автор, некого Хасена:
Нам не нужно “принятия” идей. Мы должны видеть, что наши идеи обсуждаются и оспариваются...

И как его итог:
Этот последний комментарий подводит итог. Создайте окружение, в котором программисты могут полноценно вносить свой вклад, иначе лучшие из них уйдут.

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

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

Изучите историю, программисты вышли из разнообразных прикладных областей. Лишь потом разработка ПО выросла в отдельную отрасль. В своей области имеется ввиду, что программисты вышли из банкиров, математиков, физиков, инженеров, военных и т.д. Данная отрасль не возникла на пустом месте и изначально вычислительные машины решали исключительно прикладные задачи. Только спустя много лет они стали пригодны для того чтобы лайкать котиков. К тому моменту число программистов возросло экспоненциально и в отрасли стало 90% людей чей трудовой стаж менее 5 лет. Назовите хотя бы еще одну такую отрасль в современном мире? Современные менеджеры и РП как правило из личного опыта не являются специалистами ни в IT ни в прикладной области в которой они руководят, возникает резонный вопрос, нафиг они нужны?
Современные менеджеры и РП как правило из личного опыта не являются специалистами ни в IT ни в прикладной области в которой они руководят, возникает резонный вопрос, нафиг они нужны?

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

Если говорить о менеджерах-неспециалистах, то их зарплата часто намного ниже зарплат специалистов, с которыми они работают.
Ничего подобного. Тот же «Мифический человеко-месяц» Брукса как раз рассказывает про работу менеджера проектов, причём действие происходит где-то в 70х годах. Никогда менеджеры не исчёзнут. Востребованность их только растёт, и не только в ИТ сфере.
Только вот Брукс «учёный в области теории вычислительных систем». Они изучал физику и прикладную математику. А современные менеджеры 20-30 лет в большинстве компаний они кто? Они какое отношение имеют к IT? Многие из пользоваться компом на уровне продвинутого пользователя не умеют.
Вообще не согласен. Каждый должен заниматься своим делом. Слишком сложно стать профессионалом во ВСЕХ областях. Это из разряда «Нам нужен фронтенд разработчик, который настроит нам сеть в холдинге, напишет крутой сайт, наладит работу 1С и создаст десктоп приложение на Java». Любой адекватный айтишник воспримет такое требование как бред сивой кобылы. Потому что каждая из этих задач для качественного решения требует глубоких знаний в своей области. Точно также глупо говорить, что из хорошего программиста получится хороший менеджер. Это совершенно разные области, требующие разных навыков и компетенций. И это в обозримом будущем не поменяется. А как раз наоборот. Чтобы быть хорошим программистом в будущем, придётся ещё сильнее погружаться в новые технологии. И уже не будет достаточно времени, чтобы повышать навыки в области менеджмента.

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

Менеджер-банкир знает основы банковского дела, а менеджеры IT-шники по крайней мере из тех с которыми я сталкивался, «Hello World» написать не могут. Что не скажешь о других областях. Когда я работал на производстве инженером по автоматизации мой менеджер мог и проект разработать и напряжение поменять и программу для ПЛК написать и я считаю что любой другой менеджер должен выйти из сферы в которой он руководит. Вот моя позиция.

PS На производстве тоже попадались дурачки которые только закончили ВУЗ и сразу сели «начальниками». От них были только проблемы, которые приходилось решать за них их же подчиненным. Потому что они только в теории и на бумажках знают как устроен мир, но увы в реальности мир устроен иначе.
Моя позиция в другом

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

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

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

Моя позиция основана на опыте управления, причем не в одной области.
Так что вы промазали…

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

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

Как факт того, что у вас есть опыт управления, опровергает моё утверждение?

Можете, но скорее всего крайне неэффективно. Как правило лучшие рестораторы являются шеф-поварами.

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

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

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

ТЗ должен ставить аналитик, хорошо или плохо сделана задача — определять QA и тимлид. Это не функции менеджера проектов. Вы сами-то в теме?)
Распишите ответственность и обязанности каждой роли — менеджера проектов, CEO, кого ещё хотите. И понятно станет, нужно им быть разрабами или нет.

Конечно всегда полезно знать чего тут собственно происходит. Но для управления рестораном не надо уметь готовить, для управления грузчиками — уметь погрузить, для управления программистами — уметь программировать. Достаточно общего понимания процессов, а это можно довольно быстро получить почти в любой области.
Хотя нередко бывает так, что линейный персонал (повара/грузчики/программисты) несут явный бред и управленцам приходится вникать глубже, чтобы понять в чём именно бред. Ничего, вникают, разбираются. Но это ещё у нас в России так, потому что не принято пользоваться консалтинговыми услугами.
Думать что процессы в ИТ сильно отличаются от процессов в ресторане или у грузчиков — снобизм и заблуждение. Менеджерские задачи все те же самые, проблемы — тоже.
Знаете, на самом деле есть и другой мир, в котором программисты одновременно являются хорошими аналитиками и понимают потребности бизнеса, а главное которые решают проблемы людей, а не тупо пишут код. Но к сожалению такие люди не работают с менеджерами ваших взглядов, и их достаточно мало.
Знаете, на самом деле есть и другой мир,

Уж не знаю, сколько миров у вас)) У меня подобное (да и всё остальное) происходит в одном мире. Реальном.

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

Хорошо «тупо писать код» — уже хорошо, уже большое достижение. Редко встречается.

Но к сожалению такие люди не работают с менеджерами ваших взглядов, и их достаточно мало.

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

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

Возьмите и приведите менеджера с опытом руководства командой грузчиков или официантов и поставьте его руководить программистами (не быдлокодерами) на серьёзном IT проекте (не 1С, не клепание сайтиков). Можете заодно реалити-шоу снять, я бы даже посмотрел. Но среди моих знакомых нет таких, кто бы при таком повороте не написал заявление на увольнение и не перешёл бы во вменяемую контору (благо, есть выбор).

Наверное, не следует понимать аналогию столь буквально. Менеджер разработчиков ПО- это менеджер разработчиков прежде всего. Процессы в разработке ПО не столь сильно, по-моему, отличаются от процессов разработки в, например, машиностроении или строительстве. Говорю как человек, который учился (второй вуз) на менеджера машиностроительной промышленности и занимался автоматизацией проектирования в проектно-строительной компании. Даже холивары внутри команд разработки/проектирования по типу "возьмём типовое решение" вс "изобретём велосипед" примерно те же самые.

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

Проджект менеджеры макдональдса, я уверен, в среднем существенно квалифицированнее проджект менеджеров в ИТ. Поэтому если их поставить вместо среднего ИТ менеджера, проект только выйграет.

Возьмите и приведите менеджера с опытом руководства командой грузчиков или официантов и поставьте его руководить программистами (не быдлокодерами) на серьёзном IT проекте (не 1С, не клепание сайтиков).

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

А современные менеджеры 20-30 лет в большинстве компаний они кто? Они какое отношение имеют к IT? Многие из пользоваться компом на уровне продвинутого пользователя не умеют.

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

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

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

В фантазиях ждуниора так и будет)

Ой, да ладно вам! Что за отношение к джуниорам (которое, кстати, часто встречается в саркастическом контексте) как к дебилам?
Между коллегами всегда должно быть уважительное рабочее отношение, независимо от того, кто какую позицию занимает. Если человек с малым количеством опыта предложит отличную идею (идею, заметьте, а не план ее реализации), она от этого станет хуже идеи, предложенной опытным сотрудником? Или такой человек достоин похвалы меньше, чем порицания?

Я откуда знаю? Сколько наблюдал — всегда идею посылают вместе с джуниором. Даже если идея хорошая. Но если очень нужно реализовать эту идею, то применяется хитрый трюк) Просто эту идею еще раз предлагает кто-нибудь поближе к начальству(то есть повыше рангом-должностью). И этому человеку может даже и премию выпишут. А джуниору нет. Вы прям как с луны свалились, честное слово. Не знаете что ли как дела делаются?
Конечно, это неправильно и человек достоин похвалы и так далее. Но так не везде. Увы.
ту-ду
image
Когда я пришёл на работу, то был готов изменить мир. Теперь я каждый день изо всех сил стараюсь подавить свои истинные мысли — и просто мириться с тем, как обстоят дела… Я ДЕЙСТВИТЕЛЬНО надеюсь, что руководство скоро начнёт понимать проблему

Очень знакомо, испытываю такое в каждой компании. Первый раз решил проблему радикально: стал ком директором, что позволило мне принимать решения без оглядки на кого бы то ни было.
Хотя в некоторой степени стало еще хуже. Многие аспекты жизни предприятия стал понимать намного лучше. В итоге наступать себе на горло все же нужно, ибо все сами сильно умные 8(
Мне приходится часто заворачивать идеи разработчиков и вот почему:

  • За новой идеей разработчика может мотивация которая не совпадает с целями проекта. Например он говорит «давайте сделаем это как микросервис на го», в то время как весь остальной сервер это java, C# или python. Мотивация разработчика в том что он недавно изучил Go, и он ему понравился. Менеджеру с небольшой командой может быть тяжело поддерживать зоопарк языков.
  • Не всякий разработчик опытный настолько чтобы предлагать что-то обдуманное и долгосрочно хорошее. «Давайте добавим нам tarantul, mongo, nodejs, kubernetes для этой фичи». «Я тут почитал хабр и хочу использовать <икс>.» Может ли разработчик трезво оценивать и выбирать решения или это на уровне импульсов.
  • Разработчик предлагает идею, но ответственность не несет. Не он будет разгребать негативные последствия реализации этой идеи, он может вообще сказать «ой, я пошел на новую работу, всем пока».


При этом я согласен и с этой цитатой: «Мы должны видеть, что наши идеи обсуждаются и оспариваются, а решение основано на только на ценности идеи, а не на должности её автора»

Надо вовлекать людей и обсуждать предложения, а не просто бросить «нет, мы это не делаем». На мой взгляд не надо говорить сразу «мне не нравится это идея». Есть более человеческий способ того чтобы человек получше подумал, спросить например «а что мы будем делать с <икс>». Правда проблема с некоторыми людьми остается: они не учатся генерировать идеи хорошего качества и их энтузиазм теряется.
разработчик разработчику рознь, опытные не начнут предлогать малоизученные технологии, джуниоров же и так никто не будет слушать, ведь нужно в первую очередь убедить опытных, кроме негативных последствий у любого подхода есть и позитивные именно поэтому его и выбрали, ну и да ответственность на менеджере не сильнее чем на разработчике, любой может уйти на новую работу, оставив всё как есть, разгребать последствия кстати менеджер не будет, а будут разработчики, так что это они в первую очередь пострадают
Вы мне кажется плохо представляете чем заняты PM. Подобные факапы будут разребать ПМ и только потом разработчики, так как ПМ несет ответственность за команду и принятые решения касаемо проекта. Так что какое бы решение не было принято, плохой всегда ПМ, но не команда.
Это ж как у вас построен процесс, что программист не отвечает за свои предложения и реализации? Ок я согласен, если было принято стратегическое решение всей командой, то ответственность распределяется на команду, то бишь на ПМ, Тим Лидов и линейный состав, да при таком распределении больше спроса будет с ПМ и Тим Лидов, но опять же неудачные решения должны быть отсечены опытными участника ми команды. Плюс ведущие разработчики должны понимать нужды бизнеса и обкатывать новые идеи только в рамках новых микросервисов, если есть такая возможность. А то уж очень однобокая у вас позиция получается. Мол программист за свои идеи не отвечает, следовательно право голоса у него урезано, да и в общем то вся власть у меня, как у ПМа, так что забудьте друзья про инновации =) Я согласен с вами, что внедрение технологий должно иметь бизнес мотивацию — например сокращение накладных расходов, ускорение критичных мест, улучшение масштабируемости, сокращение технического долга. Опять же крайне печально, если ваши разработчики такого не понимают, а хотят лепить технологии ради технологий — тут кстати может быть и проблема обучения разработчиков. Во всяком случае ни когда я работал ПМом, ни когда перешел в ряды разработчиков не было даже идеи о том, чтобы влепить новую технологию без бизнес-обоснования. Да и за коллегами такого не замечал.
Согласен с большинством сказанных примеров. Очень часто «идеи» генерируют джуниоры ( хотя бывают и исключения увы), которые соответственно начитались умных примеров со стек оверфлоу и в полностью пхп проект предлагают встроить нод.жс только потому что он вчера о нем прочитал и это же так круто. Может быть, но не здесь и не сейчас. Так же надо отделять «Хорошие идеи» в том проекте где они подойдут от «говнокода», который «генератор идей» считает лучше только потому что никогда не сталкивался с такой проблемой ранее и соответственно нести ответственность за который он не намерен ведь ему «разрешили» его использовать.
Менеджеры это люди, которых нанимает начальство чтобы не общаться с этими вашими программистами.
Менеджер не заставляет программиста работать, но они любят так считать. Работать заставляет нужда есть и ночевать.
Скажите, а не бизнес ли заказчик софта?
OK, если бизнес то мы программисты обслуживаем его(бизнес).
То же делает и секретарша, занимаясь документооборотом!
Не так ли?
Что получиться, если в этой статье слово «программист» заменить на слово «секретарша»?
Да, все будут крутить у виска!
Не нужно возводить разработку софта в ранг Высоких материй.
Без конечной бизнес идеи, ради которой и разрабатывается софт, разработка софта бессмысленна!
Вы, наверное, менеджер?
Труд разработчика в большинстве случаев требует гораздо большей квалификации, чем секретаря.
И когда квалифицированный хорошооплачиваемый работник предлагает идеи, он ждет конструктивной критики, а не каких-то отмашек.
Ключевое тут то, что он квалифицирован в своей области. А собственник квалифицирован в области ведения бизнеса.

Если взять гипертрофированный пример, то это как если бы выдающийся деятель в области палеонтологии давал бы советы строителям как строить дома.

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

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

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

Как минимум в 50% случаев это не так.
Ключевое тут то, что он квалифицирован в своей области. А собственник квалифицирован в области ведения бизнеса.

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

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

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


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

Можете привести конкретный пример?


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

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

Писал большой комментарий, случайно зарефрешилась страница. Из за сильно хитро%;:?#? формы комментирования браузер не сохранил текст, и хабр тоже (хабр, 21 век, что, нельзя сделать что ли нормально??). Перенабирать как то не хочется, отвечу лаконично, сорри.

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

И это время можно расходовать по разному.

Речь о том, чтобы в нем учитывалось мнение специалиста по поводу технических вопросов

В статье речь идёт не о технических вопросах, а о каких-то «идеях». И что-то мне подсказывает, что не технические вопросы реализации под этими идеями автор имел в виду.

А статья между прочим вообще о менеджерах, которых в том числе для того и нанимают, чтобы директора не дергал каждый сотрудник

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

Можете привести конкретный пример?

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

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

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

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


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

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


Например что нельзя брать проект, мы его не сможем выполнить.

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


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

Оно вам подсказывает неправильно. Цитата: "Создайте окружение, в котором программисты могут полноценно вносить свой вклад". Техническая область подразумевается по контексту.
Те, кто хочет заниматься бизнесом, делают свой бизнес или становятся менеджерами, а не программистами.


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


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


Скорее это идеи как должно работать приложение, как его развивать, как бизнесу работать и т.д.

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

Вот пусть менеджер потратит 2 предложения на обоснование отказа. Будет спор — значит сказать, что сейчас не время, обсудим это позже.

Так про это и статья :D
И это позже никогда не наступит. Ему говорят нет, но не обсуждают почему.

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

В agile, например, документирования может не быть. И это нормально поставленный процесс для aglie.

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

Ещё раз — статья не про технические знания.

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

Ну я рад за вас, что вы всем всё всегда можете объяснить и все вас всегда прекрасно понимают :D

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

Это вам оно подсказывает неправильно. С чего вы взяли, что свой вклад для программиста — это только технический?? Короче, вы упустили всю суть статьи.

Например вот строчки из оригинальной статьи автора, на которую он ссылается:
He will stop presenting ideas, asking to meet customers, and genuinely trying to understand the business.
Перевожу: Он (программист) перестанет выдавать идеи, просить встреч с пользователями, и перестанет стремиться понять бизнес.
Или ещё:
His concern for market share and business health is replaced with a concern for titles and pay scales.
Надеюсь это вас наведёт на мысли.

Между «как должно работать приложение» и «как бизнесу работать» нет никакой связи.
«Как должно работать приложение» я имел в виду с продуктовой точки зрения. И, кстати, связь есть. Прямая.

Вот прям на этом примере.
Вот вы не поняли о чём статья. И спорите со мной. Хотя вроде как понять о чём статья — несложно, там всё написано. И таких людей, которые ничего не поняли, но считают себя умнее других и свою позицию проталкивают — вот их в жизни каждый первый. Спорить с ними и объяснять как всё в реальности — нет никакой возможности. Для этого отдельной жизни не хватит.
Вот для вас это — про технические моменты. Хотя довольно очевидно, что статья не про это. Смогу я вам доказать, что она не про технические моменты? Не знаю. Как это сделать? Не понятно. Зачем мне это делать? Не понятно.
Вот про это и статья. И наши с вами комментарии.
Так про это и статья :D
И это позже никогда не наступит.

Статья про то, чтобы оно наступало.


В agile, например, документирования может не быть. И это нормально поставленный процесс для aglie.

Зато там выделенные совещания есть.


Надеюсь это вас наведёт на мысли.

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


И, кстати, связь есть. Прямая.

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


Вот вы не поняли о чём статья. И спорите со мной.

Я могу сказать то же самое)


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

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

Статья про то, чтобы оно наступало.

Взять его обычно негде.

Зато там выделенные совещания есть.

Да, и важных вопросов там и без этого дофигища.

Там нет противоречия моим словам.

Противоречия нет, но это не значит, что есть подтверждение. У автора сформулировано довольно расплывчато, если хотите — можете у него спросить, чтобы все сомнения развеять.

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

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

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

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

А если работать по Lean Startup/Agile, то часть работы регулярно придётся выбрасывать — это заложено в природе адаптивного процесса.

Вот вы не поняли о чём статья. И спорите со мной.

Я могу сказать то же самое)

Конечно. Именно об этом я и говорил. Вот он прям пример, иллюстрация к моим словам. Когда что то сложно доказать. И простая вещь выливается в дискуссию на Х часов. Вам прекрасно удалось подтвердить мои слова :)

С того, что я сам с этим сталкивался.

А вы тут причём?)) Статья не о вас персонально.

Никто не говорит о том, что программист хочет планировать продажи, заключать сделки, или персонал нанимать

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

Есть дипломы "инженер-программист" (вуз), есть "техник-программист" (техникум), есть "программист" (пту)ж

Посмотрел в свой диплом, там «информатик-экономист», задумался о смысле жизни и всего такого, в том числе о пяти годах профуканных непонятно зачем
Кто же я тогда?
Программирование/разработка это всего лишь ремесло, пусть и достаточно новое.
Программисты априори не должны лезть дальше чем того требует задача или руководитель, по этому нравится это кому то или нет, никого не волнует.
Если такой расклад не устраивает, пожалуйста, собственный бизнес, собственные проекты и делай что хочешь, если ума хватит.
Ваш подход приводит к программистам, которые «просто хотят кодировать».
Суть статьи в том, чтобы улучшить «бизнес», вовлекая разработчиков проявлять инициативу.
Хуже, когда своими попытками мотивировать, менеджмент превращает кодеров в ребят, которые не хотят кодить.

Программирование как реализация алгоритмов, их кодирование на одном или нескольких ЯП — ближе всего к ремеслу, да. Но программирование как создание программ, как разработка ПО — гораздо большее. Это, как минимум, инженерная деятельность.

Ну не совсем.
Даже в советские времена дельные рац. предложения от рядовых сотрудников принимали.
Другое дело, что предложения должны быть «рац.» А они не всегда такие.
НЛО прилетело и опубликовало эту надпись здесь
Это не совсем так. Чужая глупость может очень сильно сказаться на таком терпеливом пареньке. Очень не много компаний, где вы можете сказать, что ваш менеджер плохой. Это менеджер скажет, что вы плохой.
НЛО прилетело и опубликовало эту надпись здесь

В цитатах программистов детский сад какой-то, «я рад, что просто уволился через пять месяцев» — да ты должен был встать и уволиться через 5 минут, дурак!

Не все любители встать и уйти. Некоторым людям свойственно, оценивать, принимать взвешенные решения. Иногда жаль покидать проект, который ты поднял с нуля и вложил туда очень много сил. Так что, ситуации бывают разные. С моей точки зрения, встать и уволиться через 5 минут — это как раз таки детский сад. А вот если говорить про работу в Германии например, то тут встать и уволиться через 5 минут вообще не получится — notice period 3 месяца.

:) image

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

Просто это разные рабочие места. Послушные кодеры которые идут и пишут что сказали (не пытаясь) умничать — тоже ценный ресурс.

В советском лозунге — от каждого по способностям, (дальше не важно) упор стоит на «по способностям». Хорошая работа должна подходить характеру.

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

Со слов антисоветчиков и не такого можно прописать. А на деле, которого в СССР было качественно больше чем в РФ, по вполне объективным причинам, программист и станочник оба обладали абсолютно равными правами и работа их варьировала по интересу. И программист мог программировать отчёты Госстата на ЕС ЭВМ, а станочник мог изготовлять АМС «Венера-№».
Партия в СССР, невзирая на прогрессирующую деградацию, жить народу не только не мешала, а ещё и помогала. Задача у ней такая была, поставленная дедушками Лениным и Сталиным. От этого она и стремилась отвязаться. И отвязалась, через Горбачёва и Ельцина. И сегодня их наследники бдят, чтобы страна не развивалась, была не самостоятельной. Станочники исчезли практически, программисты все перешли на задачи западных компаний создаваемых с помощью чисто западных продуктов.
А главный принцип капитализма всегда был «Максимальная личная прибыль любой ценой». Как для хозяина средств производства, так и для его тёмной рабочей силы, обслуживающей его средства, будь то станок, или клавиатура.

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

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

Институт распределения в 80-е был более чем гибок, по личным ощущениям и опыту. Вполне могли и учесть обстоятельства. Всё было (в конце советской власти! а ведь уже чувствовалось. что человечность то убывает!) по человечески. В любом случае, на порядок человечнее, чем сегодня. Так, я получил распределение свободное, куда хотел. Были обстоятельства, чем-то пришлось пожертвовать, но зато осталось воспоминание на всю жизнь о работе в коллективе, занятом создание системы приёма и обработки наземного комплекса приёма и обработки сканерной спутниковой информации трёх уровневой (космос-самолёт-земля) системе в народохозяйственных-целях.
Другие сокурсники отработали по 2-4 года там, куда послали в счёт бесплатной учёбы в бесплатном ВУЗе государством обеспеченного качества обучения. Ни один ни разу не заикнулся о суровых лишениях или личной обиде. Некоторые пошли в армию, офицерами метеорологической службы, чтобы не работать там, куда их распределили.
Собственно, распределение тех времён, с т.з. зрелого возраста и жизненного опыта, было и будет (но не есть сегодня) признаком системы, где нужны люди, нужны средства и где есть внятные и глубоко продуманные задачи и планы масштаба страны и планеты Земля. Сравните с личными амбициями и фантазиями отдельных атомов нестройной массы населения, которую и народом то назвать сложно, из за хаотичного искусственно поддерживаемого хаоса мнений по мириадам тупейших разногласий.

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

А что такое человечность?

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

Конечно. Слова, слова, слова… болтология одна. Лозунги. На словах всё хорошо, на деле — всё по другому.

Так и в СССР на словах было всё для человека (при условии что он строит коммунизм), а не деле — обслуживал интересы системы.

Так и в СССР на словах было всё для человека (при условии что он строит коммунизм), а не деле — обслуживал интересы системы.

Т.е. вы согласны, что вышеприведёное — это в основном слова, и с делом они расходятся. Ок, так и запишем.

А про СССР вы просто не правы. И у меня есть подозрение, что у вас как в анекдоте — сам не слышал, Рабинович напел.
Но тему предлагаю не продолжать. Такие темы я веду только за деньги :D

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

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

Зачем мне труды классиков? Я штудировал первоисточники — Конституции РСФСР, СССР и РФ.

Зачем мне труды классиков?

Да и правильно, не зачем. Оставайтесь невеждой. Мне всё равно.

Я изучаю то, что полезно или интересно. Всего изучить всё равно невозможно.

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

В наших реалиях платное образование дополнительная опция к "конкурсу на бюджет". Конкурс всегда был.

Конкурс может и был всегда, но согласитесь, есть разница — когда бюджетных мест в группе 25 из 25, и когда их 8 из 25 или вовсе 3 из 25.
Шансы попасть в эту группу на бюджет — существенно разные.

В группе не имеет значение. Сравнивать надо по стране в целом. Плюс, субъективно, потребности экономики в специалистах с ВО уменьшились за счёт компьютеризации.

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

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

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

Но я работаю, зарабатываю. И мне проще купить расходники за реал, чтобы спокойно поиграть несколько часов вечером. И совсем неохота за свои деньги отхватывать от задрота, который убил неделю на то чтобы получить +1 в характеристики от бешеной ачивки (а он убил далеко не одну неделю своей жизни).

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

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

И, уж простите, но ставлю оценку похуже.
Тут другая проблема — в людях «выедающих» контент. Ты делаешь игру с циклом на 6-8 месяцев из расчёта, что люди будут играть 15-20 часов в неделю максимум. А получаешь товарищей, которые играют 15 часов в день… минимум. В итоге они весь контент проходят за месяц — вылезают на форум и начинают вопить, что админы ленивые ослы.

Приходит инвестор/директор и спрашивает «вы что действительно ленивые ослы?». И что делать? Качественный контент делается не быстро. В итоге тупо режется экспа и увеличиваются объёмы квестов. Насыпаются тупые «горизонтальные линейки», просто чтобы занять задротов… В итоге,… это плохая практика, но так оно и есть.

На эту тему я давно собираюсь написать статью. Может таки и соберусь)
Спасибо, печально. А я на удивление наоборот люблю игры которые за пару дней можно пройти.
Не могу полностью разделить эмоциональный накал статьи. Я, как разработчик, работал в разных компаниях, и тех, где идеи принимались, и тех, где они были совершенно не нужны. Разумеется, приятнее работать в первых. Но самореализация программиста является задачей менеджера ровно постольку, поскольку способствует эффективной работе. И то, что автор описывает как loose-loose в каких-то ситуациях может на самом деле быть win-loose — в пользу менеджера и компании. Менеджер программисту не отец родной, его задача обеспечить эффективную работу, а не творческий расцвет сотрудника.
Ну да, есть такие фантазёры, что… лучше бы они просто работали. Для всех лучше.
У нас в багтрекере есть категория improvement request. Пишешь, обосновываешь — и время не тратится на болтовню, и мысли в письменном виде стройнее, и требования к написанному строже, (как минимум должно быть обоснование) и все это на веки-вечные, публично для всех видимо. Всегда можно сослаться на свои заявки, ведь они задокументированы.
Как правило, когда объем такой категории переваливает за один человекогод, то на него перестают обращать внимания. Особенно если там везде сплошные критикалы и мажоры.
We need to go deeper. Давайте подумаем почему человеческие ценности (уважение к труду, радость сотрудничества, удовольствие от решения сложных задач и т.п.) разбиваются о корпоративный гранит. Разгадка простая — безблагодатность потребительская эгоцентрическая парадигма. Менеджерам не хочется вникать в созвучие фибр тонкой и глубокой программистской души, так как на кону продвижение по иерархии и доступ к кормушке.
Не подумайте, что я хиппи-антиглобалист, вовсе нет. Призываю лишь чуть чуть «подкрутить» жизненные приоритеты. И оценить, что человеческое сотрудничество и благодарность дарит ощущение полноты жизни, которое не купить. И именно по этому в начинающих фирмах как правило атмосфера намного лучше, душевнее.
Никто не будет слушать человека, который не может заставить себя слушать.
Это естественный отбор, эволюция такая.

Свое решение надо уметь обосновать, добиться одобрения, и важно (!) и после защищать его от нападок и попыток отмены / отката.
Если не автор решения, то кто же еще это будет делать??
Ну в общем «критикуешь — предлагай». Вместо программиста и менеджера можно вставить «рабочего — прораба», «главврача — доктора», и т.п. Наивно думать что это проблема уникальна.

Конечно бывают клинические случаи, или просто нововведения реально не нужны в компании — ну так ты же программист, найти новую работу тебе это 2 дня работы.
Ещё вариант. Сделать по своему. Но не всегда прокатывает )

Или сделать получается, но это последнее что получилось :)

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

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

Например если ты генеришь решения которые не совсем целям компании служат, и реализуешь их без обсуждения. К примеру потратил втихаря неделю чтоб ускорить код на 30%, в то время как вся команда пытается реализовать новую фичу, заваливая дедлайны, а со скоростью и так все было ок и запас есть.
Не думаю что программисту стоит вмешиваться в продакт, например предлагать какие-то фичи в проекте или говорить как должна работать фича. Если хороший сотрудник продакт-мэнэджер который всем этим владеет и он должен отвечать на эти вопросы и говорить что да как. И в то же время продакт мэнеджер не должен говорить как та или иная фича должна быть реализована, какие технологии зайдействованы и т.д. потому что есть тим-лид проекта у которого есть команда. Если проект большой то в нем есть еще и архитектор который отвечает за вопросы подобные выбору технологий для реализации фич. А программисту остается просто реализовывать то что обговорено с клиентом используя технологии которые предложены тим лидом и/или архитектором проекта. Так работают большинство успешных компаний.
Это проблема талантливых кодеров. Им нравится писать. Им нравится писать ради кода. Это как кузнецы, которые куют доспех.
Ошибка менеджера запрещать им этим заниматься.
Я за индивидуальность в человеке. Если направлять команду в русло: «Ты гребец №15 на нашей галере, у тебя рост 170, вес 70 кг. Ты должен грести», то через некоторое время ты получишь отличных гребцов, которые во время нападения пиратов будут дальше грести. Им нельзя будет дать в руки оружие, они не будут знать как им пользоваться. Так же и кодеры: код, новые рюшки, технологии- вещи которые влияют на развитие его как профессионала и личности будут отброшены. А подавление личности копит негатив в сторону работодателя и менеджера. Как следствие- уход или деградация. Развитие личности и кто знает, сотрудник, который завершил проект несколько лет назад вернется к вам опять- помогать его реализовывать.
Какая-то однобокая статья. Из-за чего складывается двойственное чувство. Вроде, написано всё по делу, и надо срочно брать на вооружение. С другой стороны раскрыт вопрос только с точки зрения разработчиков.
Ну хорошо, обсуждать будем. Был у меня сотрудник, который тратил по 4 часа времени своего руководителя на пропихивание гениальных идей. Некоторые были очевидными и обсосанными командой со всех сторон. Но 99% были не жизнеспособны. На некоторых мы сильно обожглись. Но даже объективное тестирование ему не помогало, и он продолжал стоять на своём. Вот если б он от нас не ушёл, мне надо было бы извинение у него просить, что я к нему не прислушивался? И, что ещё важнее, после траты моего времени на один рабочий месяц мне надо было бы прислушиваться к его идеям?
Ok. А идеи переписать всё на язык X надо обсуждать? А если у нас разработчиков на этом языке нет вообще? Или можно просто сказать: «Чувак, у нас на X пишешь, только ты. А только вот в этом модуле 100500 строк. Мы переписывать не будем, т.к. долго и дорого»?
По моему, было бы клёво, если б разработчик, до того как произнесёт своё предложение, немного его обдумал. Как он сам это делать собирается.
Одним словом, истина оказалась не в крайностях.
Эта проблема всегда была и всегда будет.
Заказчику надо просто покрасить дверь в белый цвет. Приходит талантливый Пикассо и начинает грузить всех идеями, как эту дверь можно разрисовать. Но заказчику нужно просто покрасить дверь в белый цвет, ему не нужна картина на двери.
И бОльшей частью заказчики такие. Что делать с этой командой, состоящей из одних Пикассо?
Возможно я ошибаюсь, но мне видится это дело так:
— на типовые проекты заказчиков брать бригаду маляров
— а Пикассо лучше не насиловать себя типовыми проектами, а идти в стартап или самому его организовывать
Тогда все будут на своих местах и все будут довольны.

Есть заказчики, которым не нужны типовые проекты, им нужны конкурентные преимущества. Кроме того, слово "заказчик" очень широко можно трактовать, а можно очень узко. В продуктовой компании есть заказчик? В аутсорс-компании, которые решает бизнес-задачи, а не работает по готовому ТЗ?

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

Публикации

Истории