Комментарии 119
Все чаще встречаю статьи в которых программисты жалуются на свою судьбу(начальство, "тупых" юзеров или, как здесь, плохого РМ).
Однако, работая на стороне разработчиков, а потом на стороне пользователя, могу сказать, что бывают совершенно разные ситуации.
Есть компании, где проект уже в продакшене, и от программиста требуется вовсе не полет мысли, и чудо идеи как бы все изменить к лучшему (по его мнению), а поддержка проекта и реализация нужд потребителя продукта. Причем в короткий срок, что приводит к тому, что все идеи требующие затрат времени как на обсуждение так и на реализацию лишь идеи, воспринимаются как пустая трата времени.
P.S. по моему опыту могу сказать, что при устройстве на работу(либо во время испытательного срока) практически безошибочно можно определить, что от тебя нужно фирме, человеко-ресурс или твои мысли.
Работая «изнутри», я понял что куча проблем юзеров — однотипные, но «тривиального» решения, которое можно передать в саппорт, не существует. Решения чтоб устранить целые классы проблем пользователей часто предлагались заказчику. Что-то принималось, что-то откладывалось до лучших времен. Понятно, что при выводе нового продукта на рынок (ака «Стартап»), важно зарабатывать, а баги исправить когда будет финансовая «подушка». И современный разработчик это понимает, принимает и способствует. Но когда проект живёт в таком цикле 5+ лет, то технический долг становиться неразгребаемым.
Поэтому когда Вы говорите, что пользователям нужна «поддержка продукта», то в итоге это приводит к тому, что разработчик занимается не своей прямой работой, а исправлением лажи из-за не правильной… скажем, архитектуры. И не нужно сейчас говорить про то что «архитектура» плохая. Она была заложена Х лет назад с ТЕМИ требованиями, более того, некоторые хорошие идеи были «отложены», т.к. новая кнопочка «нужна сейчас», а как оно работает пользователю\заказчику не важно. Но время никогда не выделялось на доделывание.
В итоге это приводит к тому, что куча ресурсов тратиться на саппорт, эффективность и скорость добавления новых сущностей замедляется, продуктивность и мотивация падает (ну не будет нормальный разработчик в 100-й раз писать скрипт чтоб вычистить юзер-данные).
А еще, когда разработчик предлагает «простое» и «advanced» решение проблемы, часто «advanced» продиктовано личным опытом: всё это он уже проходил на другом проекте\в другой компании и знает, что после этой кнопочки нужно будет ещё 3, которые чуть-чуть отличаются, но чтоб их добавить «потом», нужно будет с нуля переписать самую первую\простую.
Давайте рассмотрим типичную ситуацию. Есть несколько категорий работников:
1. Есть программист, который получает неплохие деньги и который кипит идеями.
2. Есть руководство (менеджер/директор) который ставит ему задачи и платит деньги из бюджета проекта.
3. Есть продажник, который занят продажей продукта. Ему без разницы как работает кнопочка, ему сам факт ее наличия делает продажи.
4. Есть заказчик/покупатель, который платит денежку за продукт, из которой формируется бюджет.
Теперь вспомним, что зарплата программиста (1.) растет регулярно (он же прокачивается, да и вообще рынок тут растет). Он начинает выламывать руки руководителям (2.) для проталкивания правильных идей, однако он не представляет потребности потребителя (4.).
Продажник (3.) примерно представляет, как та или иная функциональность повлияет на воронку продаж (а значит и на прибыль). Т.е. нужда потребителя (4.) ему сильно ближе. Однако все мы знаем, что на рынке продажников (3.) особого роста нет из-за нереально высокой конкуренции. Поэтому, он либо не доносит вообще эту информацию до руководителя (2.), либо делает это максимально аккуратно, чтобы не потерять место.
В результате руководитель (2.) опять требует от программистов (1.) не полета фантазии, а реализации конкретики, которую он смог понять от продажника (3.) и заказчика (4.). И это реально важно, т.к. он видит, что в противном случае бюджета на зарплату программиста (1.) не хватит.
Система переходит из состояния покоя в маятник, когда руководители пытаются найти баланс между бюджетом, генерируемым продажником (3.) и потребителем (4.) с одной стороны и потребностями программиста (1.) с другой. Отсюда и нарастание технического долга, и неудовлетворенность.
Понятно что схема примитивная, но к реальности она достаточно близка.
Не спорю с автором, все что написано в статье должно применять на таких проектах, где это допустимо с точки зрения бизнеса.
Второй момент, это комментарий, который приводит автор, некого Хасена:
Нам не нужно “принятия” идей. Мы должны видеть, что наши идеи обсуждаются и оспариваются...
И как его итог:
Этот последний комментарий подводит итог. Создайте окружение, в котором программисты могут полноценно вносить свой вклад, иначе лучшие из них уйдут.
Боюсь вы тут абсолютно не правы. Судя по этому комментарию человеку хочется просто поговорить. Потому что, когда у меня возникает идея, и я считаю что она достаточно стоящая, чтобы дергать руководство на ее обсуждение, я жду что ее хотя бы на оценку к аналитикам отправят, но уж точно не отвергнут.
А если бы не было автономии и разнообразия из задач, которые просто нужно сделать как сказали и в которых можно проявить инициативу и фантазию, я бы наверное уволился спустя полгода — год, если бы никто ничего не захотел менять.
Странный комментарий. Сначала он сообщает, что раньше программисты были профессионалами в своей отрасли. А потом, что им, почему-то, не нужны менеджеры.
Современные менеджеры и РП как правило из личного опыта не являются специалистами ни в IT ни в прикладной области в которой они руководят, возникает резонный вопрос, нафиг они нужны?
Чтобы не тратить дорогое время и внимание нескольких программистов на задачи, с которыми может справиться один менеджер — переговоры, присутствие на совещаниях, контроль сроков, написание отчётов, координация усилий.
Если говорить о менеджерах-неспециалистах, то их зарплата часто намного ниже зарплат специалистов, с которыми они работают.
Мне кажется, что у тебя несколько снобистская позиция. Дескать программисты эдакие гении, а менеджеры обычные дармоеды. Это как мерить среднюю температуру по больнице. Потому что есть и хреновые программисты, и замечательные менеджеры. И утверждать, что одни смогут заменить других, мне кажется слишком самонадеянно.
Менеджер-банкир знает основы банковского дела, а менеджеры IT-шники по крайней мере из тех с которыми я сталкивался, «Hello World» написать не могут. Что не скажешь о других областях. Когда я работал на производстве инженером по автоматизации мой менеджер мог и проект разработать и напряжение поменять и программу для ПЛК написать и я считаю что любой другой менеджер должен выйти из сферы в которой он руководит. Вот моя позиция.
PS На производстве тоже попадались дурачки которые только закончили ВУЗ и сразу сели «начальниками». От них были только проблемы, которые приходилось решать за них их же подчиненным. Потому что они только в теории и на бумажках знают как устроен мир, но увы в реальности мир устроен иначе.
Моя позиция в другом
Позиция понятна и очень распространена, особенно среди тех, кто никогда ничем и никем не управлял.
А я могу управлять рестораном, если я не умею готовить?
А компанией, предоставляющей услуги грузчиков, если я грузчиком ни часу не отработал?
Позиция понятна и очень распространена, особенно среди тех, кто никогда ничем и никем не управлял.
Моя позиция основана на опыте управления, причем не в одной области.
Так что вы промазали…
А я могу управлять рестораном, если я не умею готовить?
А компанией, предоставляющей услуги грузчиков, если я грузчиком ни часу не отработал?
Можете, но скорее всего крайне неэффективно. Как правило лучшие рестораторы являются шеф-поварами.
Позиция понятна и очень распространена, особенно среди тех, кто никогда ничем и никем не управлял.Моя позиция основана на опыте управления, причем не в одной области.
Так что вы промазали…
Как факт того, что у вас есть опыт управления, опровергает моё утверждение?
Можете, но скорее всего крайне неэффективно. Как правило лучшие рестораторы являются шеф-поварами.
А я вот как раз занимался общепитом и довольно хорошо знаю эту сферу.
Если в качестве критерия «лучшести ресторатора» брать качество гастрономии — тогда да, лучшими будут шеф-повара. И как правило это отдельно стоящий ресторан, не сеть.
А если брать за критерий успешность ресторана как бизнеса, то в успешном общипите почти нет руководителей (CEO и т.п.) шеф-поваров. Тем более в крупном сетевом.
Причины очевидны — приготовить хорошую еду и управлять бизнесом — совершенно разные скилы, как софт так и хард.
А про грузчиков вы чего проигнорировали?
Много вы знаете грузчиков, которые управляют такими компаниями?
Но вот поставить во главе команды инженеров человека, который вообще не в теме, — это верх маразма. Хотя бы потому, что у него нет ни малейшего понятия о том, хорошо или плохо сделана работа, да и техническую задачу грамотно поставить он не сможет по определению.
Но вот поставить во главе команды инженеров человека, который вообще не в теме, — это верх маразма. Хотя бы потому, что у него нет ни малейшего понятия о том, хорошо или плохо сделана работа, да и техническую задачу грамотно поставить он не сможет по определению.
ТЗ должен ставить аналитик, хорошо или плохо сделана задача — определять QA и тимлид. Это не функции менеджера проектов. Вы сами-то в теме?)
Распишите ответственность и обязанности каждой роли — менеджера проектов, CEO, кого ещё хотите. И понятно станет, нужно им быть разрабами или нет.
Конечно всегда полезно знать чего тут собственно происходит. Но для управления рестораном не надо уметь готовить, для управления грузчиками — уметь погрузить, для управления программистами — уметь программировать. Достаточно общего понимания процессов, а это можно довольно быстро получить почти в любой области.
Хотя нередко бывает так, что линейный персонал (повара/грузчики/программисты) несут явный бред и управленцам приходится вникать глубже, чтобы понять в чём именно бред. Ничего, вникают, разбираются. Но это ещё у нас в России так, потому что не принято пользоваться консалтинговыми услугами.
Думать что процессы в ИТ сильно отличаются от процессов в ресторане или у грузчиков — снобизм и заблуждение. Менеджерские задачи все те же самые, проблемы — тоже.
Знаете, на самом деле есть и другой мир,
Уж не знаю, сколько миров у вас)) У меня подобное (да и всё остальное) происходит в одном мире. Реальном.
в котором программисты одновременно являются хорошими аналитиками и понимают потребности бизнеса, а главное которые решают проблемы людей, а не тупо пишут код.
Хорошо «тупо писать код» — уже хорошо, уже большое достижение. Редко встречается.
Но к сожалению такие люди не работают с менеджерами ваших взглядов, и их достаточно мало.
Ну не знаю, со мной работают.
Всё это не от мира зависит, а от ситуации, от компании, от проекта.
Думать что процессы в ИТ сильно отличаются от процессов в ресторане или у грузчиков — снобизм и заблуждение. Менеджерские задачи все те же самые, проблемы — тоже.
Ага, прям представляю как гугл или фейсбук нанимают менеджера из «Макдональдс», и он проводит совещания у разработчиков.
Возьмите и приведите менеджера с опытом руководства командой грузчиков или официантов и поставьте его руководить программистами (не быдлокодерами) на серьёзном IT проекте (не 1С, не клепание сайтиков). Можете заодно реалити-шоу снять, я бы даже посмотрел. Но среди моих знакомых нет таких, кто бы при таком повороте не написал заявление на увольнение и не перешёл бы во вменяемую контору (благо, есть выбор).
Наверное, не следует понимать аналогию столь буквально. Менеджер разработчиков ПО- это менеджер разработчиков прежде всего. Процессы в разработке ПО не столь сильно, по-моему, отличаются от процессов разработки в, например, машиностроении или строительстве. Говорю как человек, который учился (второй вуз) на менеджера машиностроительной промышленности и занимался автоматизацией проектирования в проектно-строительной компании. Даже холивары внутри команд разработки/проектирования по типу "возьмём типовое решение" вс "изобретём велосипед" примерно те же самые.
Ага, прям представляю как гугл или фейсбук нанимают менеджера из «Макдональдс», и он проводит совещания у разработчиков.
Проджект менеджеры макдональдса, я уверен, в среднем существенно квалифицированнее проджект менеджеров в ИТ. Поэтому если их поставить вместо среднего ИТ менеджера, проект только выйграет.
Возьмите и приведите менеджера с опытом руководства командой грузчиков или официантов и поставьте его руководить программистами (не быдлокодерами) на серьёзном IT проекте (не 1С, не клепание сайтиков).
Ну т.е. менеджера проектов от бригадира вы не отличаете? Ок, так и запишем.
А современные менеджеры 20-30 лет в большинстве компаний они кто? Они какое отношение имеют к IT? Многие из пользоваться компом на уровне продвинутого пользователя не умеют.
Тоже самое можно сказать и о современных программистах. Да, многие пользоваться компом на уровне продвинутого пользователя не умеют.
Но какое отношение это имеет к тому, были менеджеры изначально и будут ли они в будущем? Никакого.
А это разве проблема "программист — менеджер"? В отношениях "синьор — джуниор" такой проблемы нет, все друг друга слушают?
Если джуниор скажет толковую вещь, то его похвалят
В фантазиях ждуниора так и будет)
Ой, да ладно вам! Что за отношение к джуниорам (которое, кстати, часто встречается в саркастическом контексте) как к дебилам?
Между коллегами всегда должно быть уважительное рабочее отношение, независимо от того, кто какую позицию занимает. Если человек с малым количеством опыта предложит отличную идею (идею, заметьте, а не план ее реализации), она от этого станет хуже идеи, предложенной опытным сотрудником? Или такой человек достоин похвалы меньше, чем порицания?
Конечно, это неправильно и человек достоин похвалы и так далее. Но так не везде. Увы.
Когда я пришёл на работу, то был готов изменить мир. Теперь я каждый день изо всех сил стараюсь подавить свои истинные мысли — и просто мириться с тем, как обстоят дела… Я ДЕЙСТВИТЕЛЬНО надеюсь, что руководство скоро начнёт понимать проблему
Очень знакомо, испытываю такое в каждой компании. Первый раз решил проблему радикально: стал ком директором, что позволило мне принимать решения без оглядки на кого бы то ни было.
Хотя в некоторой степени стало еще хуже. Многие аспекты жизни предприятия стал понимать намного лучше. В итоге наступать себе на горло все же нужно, ибо все сами сильно умные 8(
- За новой идеей разработчика может мотивация которая не совпадает с целями проекта. Например он говорит «давайте сделаем это как микросервис на го», в то время как весь остальной сервер это java, C# или python. Мотивация разработчика в том что он недавно изучил Go, и он ему понравился. Менеджеру с небольшой командой может быть тяжело поддерживать зоопарк языков.
- Не всякий разработчик опытный настолько чтобы предлагать что-то обдуманное и долгосрочно хорошее. «Давайте добавим нам tarantul, mongo, nodejs, kubernetes для этой фичи». «Я тут почитал хабр и хочу использовать <икс>.» Может ли разработчик трезво оценивать и выбирать решения или это на уровне импульсов.
- Разработчик предлагает идею, но ответственность не несет. Не он будет разгребать негативные последствия реализации этой идеи, он может вообще сказать «ой, я пошел на новую работу, всем пока».
При этом я согласен и с этой цитатой: «Мы должны видеть, что наши идеи обсуждаются и оспариваются, а решение основано на только на ценности идеи, а не на должности её автора»
Надо вовлекать людей и обсуждать предложения, а не просто бросить «нет, мы это не делаем». На мой взгляд не надо говорить сразу «мне не нравится это идея». Есть более человеческий способ того чтобы человек получше подумал, спросить например «а что мы будем делать с <икс>». Правда проблема с некоторыми людьми остается: они не учатся генерировать идеи хорошего качества и их энтузиазм теряется.
Менеджер не заставляет программиста работать, но они любят так считать. Работать заставляет нужда есть и ночевать.
OK, если бизнес то мы программисты обслуживаем его(бизнес).
То же делает и секретарша, занимаясь документооборотом!
Не так ли?
Что получиться, если в этой статье слово «программист» заменить на слово «секретарша»?
Да, все будут крутить у виска!
Не нужно возводить разработку софта в ранг Высоких материй.
Без конечной бизнес идеи, ради которой и разрабатывается софт, разработка софта бессмысленна!
Труд разработчика в большинстве случаев требует гораздо большей квалификации, чем секретаря.
И когда квалифицированный хорошооплачиваемый работник предлагает идеи, он ждет конструктивной критики, а не каких-то отмашек.
Если взять гипертрофированный пример, то это как если бы выдающийся деятель в области палеонтологии давал бы советы строителям как строить дома.
Это я к вопросу о том, что квалификации далеко не всегда играет ключевую роль.
Если взять гипертрофированный пример, то это как если бы выдающийся деятель в области палеонтологии давал бы советы строителям как строить дома.
Некорректный пример.
Зачем строительная фирма заводит себе департамент палеонтологии, дает ему задачи, а потом не слушает советы?
Ключевое тут то, что он квалифицирован в своей области. А собственник квалифицирован в области ведения бизнеса.Да, но программист зачастую не может быть просто квалифицированным в одной области. Как-то сравнивали программирование с переводом с человеческого на машинный. Так вот как можно переводить если не знать предметной области? (Переводить то можно, но все мы знаем как это потом получается)
Да, зачастую среди менеджеров встречаются круглые дебилы. Но это не значит, что все менеджеры идиоты. Также и среди программистов встречаются говнокодеры с синдромом вахтёра. И это опять не доказывает, что все айтишники зажравшиеся снобы.
Также и среди программистов встречаются говнокодеры с синдромом вахтёра. И это опять не доказывает, что все айтишники зажравшиеся снобы.Две противоречащие друг другу фразы.
Так же прошу заметить что я ничего плохого про менеджеров не говорил. В одной компании все примерно одинакового уровня запущенности. И каждый специалист и занимается своим делом. Но одно и то же с разных мест видно по-разному. И ВСЕГДА неслушать программиста вредит не только программисту, но и бизнесу. (Я если честного такого не встречал, мои идеи, наравне с идеями других сотрудников точно так же обговаривались, часто после неправильных идей мне потом читали азы предметной области которые я пропустил, и наоборот, если другие идеи невозможно реализовать я объяснял со своей стороны. Точно так же некоторые идеи безоговорочно внедрялись вне зависимости кто их придумал.)
А собственник квалифицирован в области ведения бизнеса.
Как минимум в 50% случаев это не так.
Ключевое тут то, что он квалифицирован в своей области. А собственник квалифицирован в области ведения бизнеса.
Ну так а что мешает сказать в ответ на идею "Ты не учитываешь то-то и то-то, поэтому мы так делать не будем"? Об этом речь, а не о том, что все предложения программистов надо принимать.
Вот бы каждый рядовой оспаривал приказы командира, и офицеры каждый раз убеждали личный состав, что приказ нужный и важный. Много бы эта армия навоевала, ага.
В наше время скорость на рынке (а значит скорость принятия решений в компании) — это всё.
Затрахаешься всем всё объяснять. Вас много, а директор один
Не надо объяснять всем и всё. Есть процесс постановки и обсуждения задачи, то есть время уже выделено. Речь о том, чтобы в нем учитывалось мнение специалиста по поводу технических вопросов, которые могут повлиять и на техническую часть и на бизнес.
А статья между прочим вообще о менеджерах, которых в том числе для того и нанимают, чтобы директора не дергал каждый сотрудник.
А во многих случаях даже объяснить невозможно, почему идея не подходит, потому что у человека тупо нет нужных знаний и опыта.
Можете привести конкретный пример?
Вот бы каждый рядовой оспаривал приказы командира, и офицеры каждый раз убеждали личный состав, что приказ нужный и важный.
В армии у офицеров больше военных знаний, чем у рядовых. А у начальника бизнеса нет таких технических знаний. Так что аналогия не то что некорректна, она полностью противоречит обсуждаемой ситуации.
Есть процесс постановки и обсуждения задачи, то есть время уже выделено.
И это время можно расходовать по разному.
Речь о том, чтобы в нем учитывалось мнение специалиста по поводу технических вопросов
В статье речь идёт не о технических вопросах, а о каких-то «идеях». И что-то мне подсказывает, что не технические вопросы реализации под этими идеями автор имел в виду.
А статья между прочим вообще о менеджерах, которых в том числе для того и нанимают, чтобы директора не дергал каждый сотрудник
Да это всё одно на разных уровнях только. Собственник — ген дир, ген дир — манагер, манагер — тим лид. Одно но — выше по иерархии народ ближе к бизнесу и вообще больше в управлении понимает, и догадывается, что его «идеи» как собаке пятая нога.
Можете привести конкретный пример?
Например что нельзя брать проект, мы его не сможем выполнить.
Нельзя брать этого человека в команду, он работу разрушит. И т.д.
В армии у офицеров больше военных знаний, чем у рядовых. А у начальника бизнеса нет таких технических знаний. Так что аналогия не то что некорректна, она полностью противоречит обсуждаемой ситуации.
Вот я не поленился, просмотрел ещё раз статью. Там совершенно нет упоминания технических знаний. Там про «идеи». Скорее это идеи как должно работать приложение, как его развивать, как бизнесу работать и т.д.
Возможно я что-то не заметил, но впечатление именно такое. В каментах кстати так и обсуждают.
И это время можно расходовать по разному.
Вот пусть менеджер потратит 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 минут, дурак!
как слабоумных всезнаек — вундеркиндов, способных только программировать.
Просто это разные рабочие места. Послушные кодеры которые идут и пишут что сказали (не пытаясь) умничать — тоже ценный ресурс.
В советском лозунге — от каждого по способностям, (дальше не важно) упор стоит на «по способностям». Хорошая работа должна подходить характеру.
В советском лозунге не имелось в виду "от каждого по его наиболее выдающимся способностям". Способен землю копать — вот лопата и копай Беломорканал. Способен самолёты конструировать — вот "шарашка" и конструируй. Партия решит, какие из твоих физических и интеллектуальных способностей ей нужны здесь и сейчас.
Партия в СССР, невзирая на прогрессирующую деградацию, жить народу не только не мешала, а ещё и помогала. Задача у ней такая была, поставленная дедушками Лениным и Сталиным. От этого она и стремилась отвязаться. И отвязалась, через Горбачёва и Ельцина. И сегодня их наследники бдят, чтобы страна не развивалась, была не самостоятельной. Станочники исчезли практически, программисты все перешли на задачи западных компаний создаваемых с помощью чисто западных продуктов.
А главный принцип капитализма всегда был «Максимальная личная прибыль любой ценой». Как для хозяина средств производства, так и для его тёмной рабочей силы, обслуживающей его средства, будь то станок, или клавиатура.
Как же по интересу при наличии института распределения? Закончил институт — будь добр работай по диплому, а не станочиником и всё равно на твои интересы партии. А при Сталине так вообще прикрепления к предприятию практиковались, по собственному уволиться нельзя было, а на другое предприятие перевести могли согласия не спрашивая.
Институт распределения в 80-е был более чем гибок, по личным ощущениям и опыту. Вполне могли и учесть обстоятельства. Всё было (в конце советской власти! а ведь уже чувствовалось. что человечность то убывает!) по человечески. В любом случае, на порядок человечнее, чем сегодня. Так, я получил распределение свободное, куда хотел. Были обстоятельства, чем-то пришлось пожертвовать, но зато осталось воспоминание на всю жизнь о работе в коллективе, занятом создание системы приёма и обработки наземного комплекса приёма и обработки сканерной спутниковой информации трёх уровневой (космос-самолёт-земля) системе в народохозяйственных-целях.
Другие сокурсники отработали по 2-4 года там, куда послали в счёт бесплатной учёбы в бесплатном ВУЗе государством обеспеченного качества обучения. Ни один ни разу не заикнулся о суровых лишениях или личной обиде. Некоторые пошли в армию, офицерами метеорологической службы, чтобы не работать там, куда их распределили.
Собственно, распределение тех времён, с т.з. зрелого возраста и жизненного опыта, было и будет (но не есть сегодня) признаком системы, где нужны люди, нужны средства и где есть внятные и глубоко продуманные задачи и планы масштаба страны и планеты Земля. Сравните с личными амбициями и фантазиями отдельных атомов нестройной массы населения, которую и народом то назвать сложно, из за хаотичного искусственно поддерживаемого хаоса мнений по мириадам тупейших разногласий.
Отличнаый выбор: или иди работать куда направили, или иди служить в армию. И где тут человечность? Задачи и планы масштаба страны и планеты Земля — это не человечность, это интересы системы.
Как пример: "Человек, его права и свободы являются высшей ценностью. Признание, соблюдение и защита прав и свобод человека и гражданина — обязанность государства." Знакомо?
Так и в СССР на словах было всё для человека (при условии что он строит коммунизм), а не деле — обслуживал интересы системы.
Так и в СССР на словах было всё для человека (при условии что он строит коммунизм), а не деле — обслуживал интересы системы.
Т.е. вы согласны, что вышеприведёное — это в основном слова, и с делом они расходятся. Ок, так и запишем.
А про СССР вы просто не правы. И у меня есть подозрение, что у вас как в анекдоте — сам не слышал, Рабинович напел.
Но тему предлагаю не продолжать. Такие темы я веду только за деньги :D
Да, слова. Но хотя бы задекларированные как цель. Если цель вообще не декларировать, то достигнуть её можно только случайно. В Союзе целью было задекларировано построение коммунизма, общества, где превыше всего общественные интересы, в современной России — капитализма, общества где превыше всего личные интересы. Шансы, что будет построено общество, где мои интересы выше общественных, выше во втором случае, хотя бы потому что не нужно менять задекларированные цели. "Дифф" меньше.
Я вот до сих пор жалею, что вместо доп.учебы, я подрабатывал где придется, ибо кушать, знаете, сильно хотелось, хотя бы пару раз в день, а на стипуху даже отличника получалось есть 1 раз в два дня. С третьего курса повезло — устроился по специальности.
В наших реалиях платное образование дополнительная опция к "конкурсу на бюджет". Конкурс всегда был.
Шансы попасть в эту группу на бюджет — существенно разные.
В итоге, мои предложения принимались, эдак через месяца три. Как правило, как идеи кого-то другого. А игра тем временем имела проблемы с монетизацией и, в итоге, продалась за бесценок конкуренту. А недавно проект вообще был дропнут.
На самом деле, я вижу только пользу в том, чтобы в игрушках можно было купить за реал то, что можно задрочить. Конечно, логично, что дети и студенты у которых полно времени должны иметь преимущество в игре. Они же потратили время и силы на развитие.
Но я работаю, зарабатываю. И мне проще купить расходники за реал, чтобы спокойно поиграть несколько часов вечером. И совсем неохота за свои деньги отхватывать от задрота, который убил неделю на то чтобы получить +1 в характеристики от бешеной ачивки (а он убил далеко не одну неделю своей жизни).
Плохо, когда в игре нет возможности, пусть и с большими усилиями получить тоже развитие, что доступно за реал. С другой стороны, ни чем не лучше, если можно получить развитие недоступное реальщику. Подписка работает плохо. Просто доступ к игре игроки не готовы покупать. Поэтому в подписку «насыпают» рулезов, что по сути тот же фритуплей.
Поэтому приход денег в игру в русскоязычном пространстве — это покупка игровых преимуществ. И если такая покупка не приводит к ожиданиям игрока, то игра загнётся от недостатка финансов (сейчас я говорю не о руле, а только о равных возможностях за деньги).
можно было купить за реал то, что можно задрочить.Простите, но если в игре нужно что-то майнить, лутить или иным способом задрачивать как Вы выразились — сразу удаляю, даже если игра понравилась — удаляю через силу, потому что это плохая игра, уничтожающая время, превращающая игрока из человека в крысу нажимающую педаль стимулирующую центр удовольствия.
И, уж простите, но ставлю оценку похуже.
Приходит инвестор/директор и спрашивает «вы что действительно ленивые ослы?». И что делать? Качественный контент делается не быстро. В итоге тупо режется экспа и увеличиваются объёмы квестов. Насыпаются тупые «горизонтальные линейки», просто чтобы занять задротов… В итоге,… это плохая практика, но так оно и есть.
На эту тему я давно собираюсь написать статью. Может таки и соберусь)
Не подумайте, что я хиппи-антиглобалист, вовсе нет. Призываю лишь чуть чуть «подкрутить» жизненные приоритеты. И оценить, что человеческое сотрудничество и благодарность дарит ощущение полноты жизни, которое не купить. И именно по этому в начинающих фирмах как правило атмосфера намного лучше, душевнее.
Это естественный отбор, эволюция такая.
Свое решение надо уметь обосновать, добиться одобрения, и важно (!) и после защищать его от нападок и попыток отмены / отката.
Если не автор решения, то кто же еще это будет делать??
Ну в общем «критикуешь — предлагай». Вместо программиста и менеджера можно вставить «рабочего — прораба», «главврача — доктора», и т.п. Наивно думать что это проблема уникальна.
Конечно бывают клинические случаи, или просто нововведения реально не нужны в компании — ну так ты же программист, найти новую работу тебе это 2 дня работы.
Или сделать получается, но это последнее что получилось :)
Но тут как — если ты таким образом генеришь хорошие решения — то молодец, тебя заметят. Иначе попросят не портить код в будущем без согласования. И это может привести к написанию подобных статей.
Например если ты генеришь решения которые не совсем целям компании служат, и реализуешь их без обсуждения. К примеру потратил втихаря неделю чтоб ускорить код на 30%, в то время как вся команда пытается реализовать новую фичу, заваливая дедлайны, а со скоростью и так все было ок и запас есть.
Ошибка менеджера запрещать им этим заниматься.
Я за индивидуальность в человеке. Если направлять команду в русло: «Ты гребец №15 на нашей галере, у тебя рост 170, вес 70 кг. Ты должен грести», то через некоторое время ты получишь отличных гребцов, которые во время нападения пиратов будут дальше грести. Им нельзя будет дать в руки оружие, они не будут знать как им пользоваться. Так же и кодеры: код, новые рюшки, технологии- вещи которые влияют на развитие его как профессионала и личности будут отброшены. А подавление личности копит негатив в сторону работодателя и менеджера. Как следствие- уход или деградация. Развитие личности и кто знает, сотрудник, который завершил проект несколько лет назад вернется к вам опять- помогать его реализовывать.
Ну хорошо, обсуждать будем. Был у меня сотрудник, который тратил по 4 часа времени своего руководителя на пропихивание гениальных идей. Некоторые были очевидными и обсосанными командой со всех сторон. Но 99% были не жизнеспособны. На некоторых мы сильно обожглись. Но даже объективное тестирование ему не помогало, и он продолжал стоять на своём. Вот если б он от нас не ушёл, мне надо было бы извинение у него просить, что я к нему не прислушивался? И, что ещё важнее, после траты моего времени на один рабочий месяц мне надо было бы прислушиваться к его идеям?
Ok. А идеи переписать всё на язык X надо обсуждать? А если у нас разработчиков на этом языке нет вообще? Или можно просто сказать: «Чувак, у нас на X пишешь, только ты. А только вот в этом модуле 100500 строк. Мы переписывать не будем, т.к. долго и дорого»?
По моему, было бы клёво, если б разработчик, до того как произнесёт своё предложение, немного его обдумал. Как он сам это делать собирается.
Одним словом, истина оказалась не в крайностях.
Заказчику надо просто покрасить дверь в белый цвет. Приходит талантливый Пикассо и начинает грузить всех идеями, как эту дверь можно разрисовать. Но заказчику нужно просто покрасить дверь в белый цвет, ему не нужна картина на двери.
И бОльшей частью заказчики такие. Что делать с этой командой, состоящей из одних Пикассо?
Возможно я ошибаюсь, но мне видится это дело так:
— на типовые проекты заказчиков брать бригаду маляров
— а Пикассо лучше не насиловать себя типовыми проектами, а идти в стартап или самому его организовывать
Тогда все будут на своих местах и все будут довольны.
Есть заказчики, которым не нужны типовые проекты, им нужны конкурентные преимущества. Кроме того, слово "заказчик" очень широко можно трактовать, а можно очень узко. В продуктовой компании есть заказчик? В аутсорс-компании, которые решает бизнес-задачи, а не работает по готовому ТЗ?
Да, у кого деньги есть и кто готов платить за конкурентные преимущества, тому эти конкурентные преимущества можно делать. Но эти конкурентные преимущества делаются не на уровне программирования и кодирования (разве что оптимизация кода), а на уровне продукта и ТЗ. Если программист хочет быть одновременно и продукт-менеджером, писать сам ТЗ и одновременно программистом — не вопрос, таких надо только приветствовать, которые двойную работу делают за одну или полторы зарплаты. Но если программист не хочет быть продукт-менеджером, писателем ТЗ, тогда надо делать то, что написано в спецификации. Вопросы по ТЗ спецификации конечно приветствуются, потому что ТЗ из головы на 50 страниц написать и нигде не ошибиться — это редко кто сможет. Да, можно это красиво закодировать, но кроме тимлида это никто не оценит. Бизнесу без разницы, что там под капотом, лишь бы не падало и свои функции выполняло.
Менеджерам пора проснуться