[Maksim_2444 11]

19 минут назад, _3m сказал:

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

У Вас слишком завышенная самооценка. 

 

С одной стороны это хорошо, но может выйти боком.

 

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

 

Хотя в Вашем окружении возможно именно так, это не значит что у всех так же

[dxp 53]

18 часов назад, _3m сказал:

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

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

[makc 207]

2 часа назад, dxp сказал:

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

Думаете они (менеджеры) всего этого не понимают? Я думаю все более менее адекватные прекрасно это всё понимают, но им хотелось бы, чтобы было как написано выше. Однако так не получается, т.к. невозможно с одной стороны делегировать какому-нибудь разработчику ответственность и вместе с ней контекст определенной части разработки, а с другой стороны в любой момент иметь возможность заменить его на другого, поскольку контекст будет утерян. Новый разработчик, пришедший на замену, обладая необходимой квалификацией обязательно со временем разберётся, но простой в разработке будет неизбежно и он будет тем больше, чем большая часть контекста/ответственности ушла с прошлым разработчиком. И да, не всё можно задокументировать, формализовать и т.д., поэтому большая часть контекста всегда живёт в голове разработчика в виде опыта, идей и т.п. нематериальных сущностей. Хороший менеджер должен это понимать. А когда менеджер неадекват или подходит к любой методологии с позиций карго-культа (типа вот она серебряная пуля, вот теперь-то заживём по-новому и супер-эффективно), то тот же скрам теряет что-то и очень легко может превратиться в срам или скам, что зачастую и происходит. 😅 Хотя сам по себе скрам не плох и не хорош. "Всё есть яд и всё есть лекарство. Только доза делает лекарство ядом и яд лекарством." (С) Парацельс. Важно про это не забывать и во всём знать меру.

[jcxz 213]

3 часа назад, makc сказал:

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

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

Имхо - подробного документирования требуют манагеры, которые не разбираются в том процессе, которым они руководят.

3 часа назад, makc сказал:

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

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

[makc 207]

6 минут назад, jcxz сказал:

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

И в этот момент мы приходим к главному вопросу: что же делать? Менеджерам не хочется или не можется в разработку, а разработчикам противно или не хочется заниматься менеджерскими задачами, т.к. разрабатывать (творить) всяко приятнее и интереснее. Как перекинуть мостики между этими двумя непримеримыми лагерями?

[jcxz 213]

7 минут назад, makc сказал:

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

У меня нет ответа на этот вопрос. Да, думаю, что простого решения в этом вопросе и не существует. Волшебной пилюли. К сожалению.

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

 

PS: Может издать какой-то указ  , что на должности руководителей разработчиками, допустимо назначать только людей, которые ранее сами хоть немного поработали разработчиками? А не чистых рукамиводителей? Может тогда и все эти скрамы будут не так нужны?

PPS: На исключительную истину не претендую.

[dxp 53]

Scrum, всё, вот его убийца: A Better Way to Manage Projects

[makc 207]

8 минут назад, jcxz сказал:

У меня нет ответа на этот вопрос. Да, думаю, что простого решения в этом вопросе и не существует. Волшебной пилюли. К сожалению.

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

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

[Maksim_2444 11]

9 минут назад, dxp сказал:

Scrum, всё, вот его убийца: A Better Way to Manage Projects

 

Признаюсь, я удивлен такой позицией!

 

Вы на столько против систематизации в проектах, что не пожалели своего времени и денег на создание говно сайта!

 

Браво. Теперь я точно знаю, что Scrum, всё!

[_3m 6]

1 час назад, jcxz сказал:

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

Имхо - подробного документирования требуют манагеры, которые не разбираются в том процессе, которым они руководят.

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

[makc 207]

51 минуту назад, _3m сказал:

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

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

[dxp 53]

1 час назад, Maksim_2444 сказал:

Признаюсь, я удивлен такой позицией!

 

Вы на столько против систематизации в проектах, что не пожалели своего времени и денег на создание говно сайта!

 

Я создал этот сайт?!! У вас больное воображение, сходите к профильному доктору.

6 часов назад, makc сказал:

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

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

[makc 207]

7 минут назад, dxp сказал:

Не факт. И чем сложнее тема, тем труднее найти преемника. Нередко бывает так, что новому человеку проще полностью или частично переделать "почти готовое", а это потери времени уж совсем немалые.

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

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

10 минут назад, dxp сказал:

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

Совершенно верно. Чтобы понять это  на 110% достаточно разок попробовать заменить кого-нибудь в середине проекта без понимания, что и как было сделано, почему оно такое и что с этим можно/нужно делать дальше. После пары таких опытов уверенности хоть отбавляй. Но откуда взять такой опыт менеджерам? Они это видят со своей стороны как топтание на месте и чуть ли не саботаж... Донести до них трудности получается редко.

12 минут назад, dxp сказал:

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

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

[jcxz 213]

34 минуты назад, makc сказал:

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

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

Вот скажем - много ли здесь участников, кто полностью прочитал мануал на свой микроконтроллер или используемые чипы? От корки до корки? есть хоть один??   А теперь представьте - если бы разработчики вашего микроконтроллера впендюрили в мануал не только реализованное, но и все забракованные решения? Представили?  Скажем писали бы: Регистр статуса UART реализован так то, но так же был вариант сделать его ещё так-то (вариант_1) и так-то (вариант_2), но не сделали потому-то и потому-то. И так про каждый узел МК.  

Когда я изучал си++ (много лет назад), то у меня было два учебника: Первый толстый (сантиметров 5 книга в твёрдом переплёте) и дорогой. С кучей воды и лирических отступлений. И была вторая - тонкая синяя книжица, где были даны только сухие факты только касающиеся предмета. И причём - полезной инфы она содержала раза в 2-3 больше чем первая. И изучать по первой было совершенно невозможно. Тонул в море ненужной инфы и лирических отступлений. Зато вторая - просто на ура.

 

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

[makc 207]

6 минут назад, jcxz сказал:

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

Да, есть и такая проблема.

6 минут назад, jcxz сказал:

Вот скажем - много ли здесь участников, кто полностью прочитал мануал на свой микроконтроллер или используемые чипы? От корки до корки? есть хоть один??   А теперь представьте - если бы разработчики вашего микроконтроллера впендюрили в мануал не только реализованное, но и все забракованные решения? Представили?  Скажем писали бы: Регистр статуса UART реализован так то, но так же был вариант сделать его ещё так-то (вариант_1) и так-то (вариант_2), но не сделали потому-то и потому-то. И так про каждый узел МК.  

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