Maksim_2444 11 24 июня Опубликовано 24 июня · Жалоба 19 минут назад, _3m сказал: О, манагер пожаловал. Конечно оно так... ровно до момента когда требуется создать изделие с жесткими ограничениями хотя бы по одному критерию: стоимость, энергопотребление, производительность, отсутствие или "китайскость" документации на ключевой компонент например cpu... Тогда оказывается что толпа обезьянок совершенно бесполезна и все-таки нужен гуру. У Вас слишком завышенная самооценка. С одной стороны это хорошо, но может выйти боком. Не в коем разе не занижаю уровень Ваших знаний, однако называть Ваших коллег "обезьянками" - плохая идея. Хотя в Вашем окружении возможно именно так, это не значит что у всех так же 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 53 25 июня Опубликовано 25 июня · Жалоба 18 часов назад, _3m сказал: ровно до момента когда требуется создать изделие с жесткими ограничениями хотя бы по одному критерию: стоимость, энергопотребление, производительность, отсутствие или "китайскость" документации на ключевой компонент например cpu... Кроме того, ещё когда нужно грамотно собрать все эти компоненты в единую гармоничную сущность (прибор, комплекс). А чтобы это собралось, это нужно изначально спроектировать, т.е. нужны люди, способные системно охватывать проблематику предметной области, а это требует недюжинного опыта, квалификации и глубокого погружения в предметную область, из-за чего даже замена одного гуру другим приводит к проблемам хотя бы в виде изрядной задержки, пока новый человек не "въедет" в тематику. А них там всё просто -- берёшь из пула и всё. Видимо задачи такие, а с по-настоящему сложными разработками не сталкивались. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 207 25 июня Опубликовано 25 июня · Жалоба 2 часа назад, dxp сказал: А них там всё просто -- берёшь из пула и всё. Видимо задачи такие, а с по-настоящему сложными разработками не сталкивались. Думаете они (менеджеры) всего этого не понимают? Я думаю все более менее адекватные прекрасно это всё понимают, но им хотелось бы, чтобы было как написано выше. Однако так не получается, т.к. невозможно с одной стороны делегировать какому-нибудь разработчику ответственность и вместе с ней контекст определенной части разработки, а с другой стороны в любой момент иметь возможность заменить его на другого, поскольку контекст будет утерян. Новый разработчик, пришедший на замену, обладая необходимой квалификацией обязательно со временем разберётся, но простой в разработке будет неизбежно и он будет тем больше, чем большая часть контекста/ответственности ушла с прошлым разработчиком. И да, не всё можно задокументировать, формализовать и т.д., поэтому большая часть контекста всегда живёт в голове разработчика в виде опыта, идей и т.п. нематериальных сущностей. Хороший менеджер должен это понимать. А когда менеджер неадекват или подходит к любой методологии с позиций карго-культа (типа вот она серебряная пуля, вот теперь-то заживём по-новому и супер-эффективно), то тот же скрам теряет что-то и очень легко может превратиться в срам или скам, что зачастую и происходит. 😅 Хотя сам по себе скрам не плох и не хорош. "Всё есть яд и всё есть лекарство. Только доза делает лекарство ядом и яд лекарством." (С) Парацельс. Важно про это не забывать и во всём знать меру. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 213 25 июня Опубликовано 25 июня · Жалоба 3 часа назад, makc сказал: И да, не всё можно задокументировать, формализовать и т.д., поэтому большая часть контекста всегда живёт в голове разработчика в виде опыта, идей и т.п. нематериальных сущностей. Хороший менеджер должен это понимать. Ещё многие такие не понимают, что на всё это документирование тоже нужно время. И чем более подробное документирование требуют - тем больше на это нужно времени. Это всё замедляет разработку. И почему-то это замедление ещё и вызывает удивление потом. Имхо - подробного документирования требуют манагеры, которые не разбираются в том процессе, которым они руководят. 3 часа назад, makc сказал: когда менеджер неадекват или подходит к любой методологии с позиций карго-культа (типа вот она серебряная пуля, вот теперь-то заживём по-новому и супер-эффективно), то тот же скрам теряет что-то и очень легко может превратиться в срам или скам, что зачастую и происходит. Согласен - очень частое явление. И думаю опять-же - проистекает такое из-за некомпетентности манагеров в прикладной области. Имхо - менеджеры, разбирающиеся в тематике, гораздо менее склонны требовать следования подобным системам. Потому как они и без этого могут контролировать процесс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 207 25 июня Опубликовано 25 июня · Жалоба 6 минут назад, jcxz сказал: Согласен - очень частое явление. И думаю опять-же - проистекает такое из-за некомпетентности манагеров в прикладной области. Имхо - менеджеры, разбирающиеся в тематике, гораздо менее склонны требовать следования подобным системам. Потому как они и без этого могут контролировать процесс. И в этот момент мы приходим к главному вопросу: что же делать? Менеджерам не хочется или не можется в разработку, а разработчикам противно или не хочется заниматься менеджерскими задачами, т.к. разрабатывать (творить) всяко приятнее и интереснее. Как перекинуть мостики между этими двумя непримеримыми лагерями? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 213 25 июня Опубликовано 25 июня · Жалоба 7 минут назад, makc сказал: Как перекинуть мостики между этими двумя непримеримыми лагерями? У меня нет ответа на этот вопрос. Да, думаю, что простого решения в этом вопросе и не существует. Волшебной пилюли. К сожалению. Но я много раз замечал, что работать под руководством начальника, разбирающегося в тематике (хоть немного) - гораздо приятнее. И эффективнее. И результат лучше и быстрее получается. PS: Может издать какой-то указ , что на должности руководителей разработчиками, допустимо назначать только людей, которые ранее сами хоть немного поработали разработчиками? А не чистых рукамиводителей? Может тогда и все эти скрамы будут не так нужны? PPS: На исключительную истину не претендую. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 53 25 июня Опубликовано 25 июня · Жалоба Scrum, всё, вот его убийца: A Better Way to Manage Projects Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 207 25 июня Опубликовано 25 июня · Жалоба 8 минут назад, jcxz сказал: У меня нет ответа на этот вопрос. Да, думаю, что простого решения в этом вопросе и не существует. Волшебной пилюли. К сожалению. Но я много раз замечал, что работать под руководством начальника, разбирающегося в тематике (хоть немного) - гораздо приятнее. И эффективнее. И результат лучше и быстрее получается. Совершенно верно, человек с практическим опытом может куда лучше держать руку на пульсе разработки, не пережимая при этом ничего и гораздо лучше осознавая риски процесса. Но вот чтобы подготовить таких специалистов нужно их как-то мотивировать и развивать в направлении навыков управления коллективом. Желательно без сильного отрыва от производства и с соответствующим повышением ЗП. Но это уже вопрос к более высокому руководству... А я на практике не видел, чтобы оно этим интересовалось приблизительно ни разу. Поэтому обычно в менеджеры идут неудачливые разработчики (не идёт разработка или получается фигня), а иногда и сильно обиженные разработчики (непринятые коллективом/коллегами). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maksim_2444 11 25 июня Опубликовано 25 июня · Жалоба 9 минут назад, dxp сказал: Scrum, всё, вот его убийца: A Better Way to Manage Projects Признаюсь, я удивлен такой позицией! Вы на столько против систематизации в проектах, что не пожалели своего времени и денег на создание говно сайта! Браво. Теперь я точно знаю, что Scrum, всё! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 6 25 июня Опубликовано 25 июня · Жалоба 1 час назад, jcxz сказал: Ещё многие такие не понимают, что на всё это документирование тоже нужно время. И чем более подробное документирование требуют - тем больше на это нужно времени. Это всё замедляет разработку. И почему-то это замедление ещё и вызывает удивление потом. Имхо - подробного документирования требуют манагеры, которые не разбираются в том процессе, которым они руководят. И практически никто не понимает необходимости и не документирует неудачные ходы, отброшенные варианты решения поставленной задачи. При разработке необходимо знать не только как сделано но и почему именно так а не каким либо другим образом. Эта информация остается только в памяти зачинателей проекта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 207 25 июня Опубликовано 25 июня · Жалоба 51 минуту назад, _3m сказал: И практически никто не понимает необходимости и не документирует неудачные ходы, отброшенные варианты решения поставленной задачи. При разработке необходимо знать не только как сделано но и почему именно так а не каким либо другим образом. Эта информация остается только в памяти зачинателей проекта. Как раз об этом контексте я и говорил выше. Но как его передать? Если всё это документировать, то время разработки растягивается очень очень сильно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 53 25 июня Опубликовано 25 июня · Жалоба 1 час назад, Maksim_2444 сказал: Признаюсь, я удивлен такой позицией! Вы на столько против систематизации в проектах, что не пожалели своего времени и денег на создание говно сайта! Я создал этот сайт?!! У вас больное воображение, сходите к профильному доктору. 6 часов назад, makc сказал: Новый разработчик, пришедший на замену, обладая необходимой квалификацией обязательно со временем разберётся Не факт. И чем сложнее тема, тем труднее найти преемника. Нередко бывает так, что новому человеку проще полностью или частично переделать "почти готовое", а это потери времени уж совсем немалые. Но по главному вопросу у нас консенсус: нету никакой такой простой взаимозамеяемости, кроме совсем уж простых задач. И чем сложнее задачи, тем замены стоят дороже (если вообще возможны -- доводилось наблюдать, когда уходил специалист, и тематика глохла, потому что замену адекватную найти в приемлемые сроки не могли. С квалифицированными кадрами всегда тяжело, потому что их мало, и они всем нужны, потому что "кадры решают всё". Кадры, не срамы). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 207 25 июня Опубликовано 25 июня · Жалоба 7 минут назад, dxp сказал: Не факт. И чем сложнее тема, тем труднее найти преемника. Нередко бывает так, что новому человеку проще полностью или частично переделать "почти готовое", а это потери времени уж совсем немалые. Конечно не факт, написано может быть сверхэффективно, но при этом совершенно немодифицируемо. Более того, у меня были такие прецеденты с моим собственным кодом, который я написал несколько лет назад и потом спустя время мне потребовалось внести в него корректировки. В итоге получилось, что проще его оказалось переписать заново, а не пытаться вылечить от наведённых новыми правками багов. А что уж говорить про нового разработчика, которому потребовалось подхватить знамя... Но, с другой стороны, что один человек создал, другой завсегда разобрать и понять сможет. Вопрос времени/желания/целесообразности. Но это всё дополнительные затраты, задержки и потенциально снижение качества. Поэтому менять разработчиков на проекте ... ну такое. (с) 10 минут назад, dxp сказал: Но по главному вопросу у нас консенсус: нету никакой такой простой взаимозамеяемости, кроме совсем уж простых задач. Совершенно верно. Чтобы понять это на 110% достаточно разок попробовать заменить кого-нибудь в середине проекта без понимания, что и как было сделано, почему оно такое и что с этим можно/нужно делать дальше. После пары таких опытов уверенности хоть отбавляй. Но откуда взять такой опыт менеджерам? Они это видят со своей стороны как топтание на месте и чуть ли не саботаж... Донести до них трудности получается редко. 12 минут назад, dxp сказал: И чем сложнее задачи, тем замены стоят дороже (если вообще возможны -- доводилось наблюдать, когда уходил специалист, и тематика глохла, потому что замену адекватную найти в приемлемые сроки не могли. С квалифицированными кадрами всегда тяжело, потому что их мало, и они всем нужны, потому что "кадры решают всё". Кадры, не срамы). На самом деле нужны все, и квалифицированные разработчики, и квалифицированные менеджеры, которые понимают в риск-менеджмент и умеют сглаживать углы в процессе разработки. Любой большой проект - это командная игра, один разработчик, каким бы он ни был гением, горы не свернёт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 213 25 июня Опубликовано 25 июня · Жалоба 34 минуты назад, makc сказал: Как раз об этом контексте я и говорил выше. Но как его передать? Если всё это документировать, то время разработки растягивается очень очень сильно. Не только это. Как показывает опыт - сейчас люди не читают даже документацию к реализованному пути разработки. Или комментарии к исходникам. Если они более одной строчки. Что уж говорить о нереализованных путях или невыстреливших идеях. Клиповое мышление. Вот скажем - много ли здесь участников, кто полностью прочитал мануал на свой микроконтроллер или используемые чипы? От корки до корки? есть хоть один?? А теперь представьте - если бы разработчики вашего микроконтроллера впендюрили в мануал не только реализованное, но и все забракованные решения? Представили? Скажем писали бы: Регистр статуса UART реализован так то, но так же был вариант сделать его ещё так-то (вариант_1) и так-то (вариант_2), но не сделали потому-то и потому-то. И так про каждый узел МК. Когда я изучал си++ (много лет назад), то у меня было два учебника: Первый толстый (сантиметров 5 книга в твёрдом переплёте) и дорогой. С кучей воды и лирических отступлений. И была вторая - тонкая синяя книжица, где были даны только сухие факты только касающиеся предмета. И причём - полезной инфы она содержала раза в 2-3 больше чем первая. И изучать по первой было совершенно невозможно. Тонул в море ненужной инфы и лирических отступлений. Зато вторая - просто на ура. PS: Слышал умную мысль: Если раньше (в предыдущие века) человек сталкивался с недостатком информации (и усилия мозга направлялись на максимальный сбор и накопление максимального количества информации), то нынче люди живут в условиях переизбытка информации (и усилия мозга больше тратятся уже на отсеивание океана ненужной инфы, чем на поиск дополнительной инфы). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 207 25 июня Опубликовано 25 июня · Жалоба 6 минут назад, jcxz сказал: Не только это. Как показывает опыт - сейчас люди не читают даже документацию к реализованному пути разработки. Или комментарии к исходникам. Если они более одной строчки. Что уж говорить о нереализованных путях или невыстреливших идеях. Клиповое мышление. Да, есть и такая проблема. 6 минут назад, jcxz сказал: Вот скажем - много ли здесь участников, кто полностью прочитал мануал на свой микроконтроллер или используемые чипы? От корки до корки? есть хоть один?? А теперь представьте - если бы разработчики вашего микроконтроллера впендюрили в мануал не только реализованное, но и все забракованные решения? Представили? Скажем писали бы: Регистр статуса UART реализован так то, но так же был вариант сделать его ещё так-то (вариант_1) и так-то (вариант_2), но не сделали потому-то и потому-то. И так про каждый узел МК. Пример некорректный, т.к. мануал на МК это документация для потребителя, а мы говорим выше про внутреннюю документацию для коллег разработчиков. Она, как правило, до пользователя доходит только в виде далёких отголосков (например, в виде тех же мануалов на МК). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться