В дебрях водопада
Aug. 30th, 2018 10:00 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЛикбез по поводу комментария gineer, который не хочет регистрироваться на DW.
Удивительно, что мне приходится это писать, но всё-таки придётся озвучить совершенно базовые принципы, которые принимаются как аксиомы для всего, что я пишу на тему IT.
1. Не все проблемы решаются на уровне программиста.
2. Не все проблемы решаются в рамках бюджета: денег, времени, персонала и технических средств.
3. Не все проблемы решаются в тот момент, когда они обнаружены.
Дальше следуют совсем элементарные вещи типа "Не все проблемы надо решать", но остановлюсь на трёх.
Программисту поставили задачу - он не может её решить или решение требует танцев с бубнами.
Что принято делать в такой ситуации?
Брать бубен и танцевать.
Что надо делать?
Передавать ответственность менеджеру.
Да, сюда может входить решение "выбросить код и переписать всё заново". И, да, я видел, как такое решение принималось в реальном проекте.
Естественно, это редкие светлые моменты посреди тёмного царства. Но они бывают.
Что делать, если решение проблемы маловероятно в ограничениях бюджета?
Стандартное решение: поменять критерии качества и загнать программистов в переработки. Естественно, не оплачиваемые.
Основная причина того, почему я ушёл из менеджмента, это типичный паттерн: "Менять ничего нельзя! Денег больше не будет! Надо сделать вчера. Мотивируй людей, чтобы они сделали быстро и качественно. Ты менеджер. Это твоя обязанность."
Да, бывает и по-другому. В том числе я видел как меняли сроки, добавляли людей, покупали тулы. И постановку задачи тоже меняли.
Выбитые в камне требования в техническом задании при ближайшем рассмотрении оказываются не такими и вечными. Практически всегда можно найти оптимальное решение, устраивающее заказчика и выполнимое разработчиками. Даже в том случае, когда люди, продавшие чудо утверждают, что всё продано и непоколебимо.
Естественно, в этом случае вместо того, чтобы продавить заказчику глюкавую кривую софтину, свалив все ошибки на разработчиков, отделу продаж придётся говорить с инженерами на равных. Но там, где результаты работы воплощают в металле, это до сих пор делают. И делают успешно.
Естественно, далеко не везде. Культура уходит, но она всё ещё жива.
Третий аспект самый замечательный: "Машина мчится по серпантину. Педаль газа заклинило. Тормоза не работают. Что будешь делать?"
Как-то на визитке я в шутку написал "ясновидец". Потому что одно из продаваемых умений - это определять ранних предвестников. Причём, не на интуиции по типу "Мы должны взять новомодную методику, потому что у та, что сейчас используем, не правильная". Я могу предсказывать будущее на основе фактов, логических доказательств и измерений.
Да, я на самом деле приходил к вышестоящему начальству с заявлениями "Эта технология не будет работать потому-то и потому-то. Мы дойдём до такого уровня, а дальше начнутся такие-то проблемы." или "Скорость снижения потока ошибок в системе на этом графике показывает, что нам не удастся выпустить стабильную версию к намеченному сроку."
И в большинстве случаев ответ был совершенно стандартный.
Но на моём профессиональном пути встречался и адекватный менеджмент, который не впадал в панику, а принимал меры.
И машина выходила на опасный участок с работающими тормозами или ехала в обход по тому пути, который не представлял опасности при имеющихся неполадках.
Причём, для систем, воплощаемых в металле или относящихся к категории mission critical такой подход - это стандарт. Не в том смысле, что инженеры могут доказать в числах неизбежность будущих проблем, а в том, что менеджмент учитывает риски и не боится с ними работать.
Вплоть до сворачивания невыполнимых проектов на ранних фазах.
Удивительно, что мне приходится это писать, но всё-таки придётся озвучить совершенно базовые принципы, которые принимаются как аксиомы для всего, что я пишу на тему IT.
1. Не все проблемы решаются на уровне программиста.
2. Не все проблемы решаются в рамках бюджета: денег, времени, персонала и технических средств.
3. Не все проблемы решаются в тот момент, когда они обнаружены.
Дальше следуют совсем элементарные вещи типа "Не все проблемы надо решать", но остановлюсь на трёх.
Программисту поставили задачу - он не может её решить или решение требует танцев с бубнами.
Что принято делать в такой ситуации?
Брать бубен и танцевать.
Что надо делать?
Передавать ответственность менеджеру.
Да, сюда может входить решение "выбросить код и переписать всё заново". И, да, я видел, как такое решение принималось в реальном проекте.
Естественно, это редкие светлые моменты посреди тёмного царства. Но они бывают.
Что делать, если решение проблемы маловероятно в ограничениях бюджета?
Стандартное решение: поменять критерии качества и загнать программистов в переработки. Естественно, не оплачиваемые.
Основная причина того, почему я ушёл из менеджмента, это типичный паттерн: "Менять ничего нельзя! Денег больше не будет! Надо сделать вчера. Мотивируй людей, чтобы они сделали быстро и качественно. Ты менеджер. Это твоя обязанность."
Да, бывает и по-другому. В том числе я видел как меняли сроки, добавляли людей, покупали тулы. И постановку задачи тоже меняли.
Выбитые в камне требования в техническом задании при ближайшем рассмотрении оказываются не такими и вечными. Практически всегда можно найти оптимальное решение, устраивающее заказчика и выполнимое разработчиками. Даже в том случае, когда люди, продавшие чудо утверждают, что всё продано и непоколебимо.
Естественно, в этом случае вместо того, чтобы продавить заказчику глюкавую кривую софтину, свалив все ошибки на разработчиков, отделу продаж придётся говорить с инженерами на равных. Но там, где результаты работы воплощают в металле, это до сих пор делают. И делают успешно.
Естественно, далеко не везде. Культура уходит, но она всё ещё жива.
Третий аспект самый замечательный: "Машина мчится по серпантину. Педаль газа заклинило. Тормоза не работают. Что будешь делать?"
Как-то на визитке я в шутку написал "ясновидец". Потому что одно из продаваемых умений - это определять ранних предвестников. Причём, не на интуиции по типу "Мы должны взять новомодную методику, потому что у та, что сейчас используем, не правильная". Я могу предсказывать будущее на основе фактов, логических доказательств и измерений.
Да, я на самом деле приходил к вышестоящему начальству с заявлениями "Эта технология не будет работать потому-то и потому-то. Мы дойдём до такого уровня, а дальше начнутся такие-то проблемы." или "Скорость снижения потока ошибок в системе на этом графике показывает, что нам не удастся выпустить стабильную версию к намеченному сроку."
И в большинстве случаев ответ был совершенно стандартный.
Но на моём профессиональном пути встречался и адекватный менеджмент, который не впадал в панику, а принимал меры.
И машина выходила на опасный участок с работающими тормозами или ехала в обход по тому пути, который не представлял опасности при имеющихся неполадках.
Причём, для систем, воплощаемых в металле или относящихся к категории mission critical такой подход - это стандарт. Не в том смысле, что инженеры могут доказать в числах неизбежность будущих проблем, а в том, что менеджмент учитывает риски и не боится с ними работать.
Вплоть до сворачивания невыполнимых проектов на ранних фазах.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2018-08-30 10:31 am (UTC)все доводы извлекает исключительно из своей картины мира, делая вид, что других существовать не может:)
no subject
Date: 2018-08-30 11:14 am (UTC)Вы меня там отчитали, за то что "слишком личное",
а теперь тут отчитываете... уже за то... а за что собственно?
2. Это проблема? Или такое ПОЗИТИВНОЕ решение?
В стиле Карлсона "Пустяки! Дело то житейское". %)
3. Гм... я вроде где-то чему-то подобному оппонировал?
""Программисту поставили задачу - он не может её решить или решение требует танцев с бубнами.
Что принято делать в такой ситуации?
Брать бубен и танцевать.
Что надо делать?
Передавать ответственность менеджеру.""
Программист НЕ МОЖЕТ ЗНАТЬ заранее, потребует оно танцев или нет.
Иногда ВПЛОТЬ до последнего момента.
А таски... часто имеют свойство сделал на 99% == не сделал на 100%
А еще лучше НЕ СДЕЛАЛ 100% И ПОДВЕЛ КОМАНДУ, ТИМЛИДА и КОМПАНИЮ...
по крайней мере в глазах и словах менеджера и команды.
\\Да, сюда может входить решение "выбросить код и переписать всё заново". И, да, я видел, как такое решение принималось в реальном проекте.
И я... и не просто видел, а и участвовал.
Бьешь себя в грудь коленом, извиняешся,
что мол вот так, переоценил свои силы и т.п. %)
\\Выбитые в камне требования в техническом задании при ближайшем рассмотрении оказываются не такими и вечными. Практически всегда можно найти оптимальное решение, устраивающее заказчика и выполнимое разработчиками. Даже в том случае, когда люди, продавшие чудо утверждают, что всё продано и непоколебимо.
Вот интересно... а это разве не Эджайл? ;)
Что надо мол мелкие итерации, взиамодействие с заказчиком, стендапы с разработчиками...
\\Вплоть до сворачивания невыполнимых проектов на ранних фазах.
Спасибо за лучик света в темном царстве.
У ВАС не картина мира
Date: 2018-08-30 11:15 am (UTC)no subject
Date: 2018-08-30 11:26 am (UTC)Свои самые длинные дискуссии я вёл, когда интенсивно разрабатывал на том же С++. Потому что компиляция проекта долгая. Ждать просто так лень. Да и ошибки, пойманные в тестах, ставят под сомнение веру в человечество - надо как-то отвлекаться от грустных мыслей.
Re: У ВАС не картина мира
Date: 2018-08-30 11:27 am (UTC)no subject
Date: 2018-08-30 11:36 am (UTC)Не решаются на уровне программиста != Не решаются
а теперь тут отчитываете...
Я никого не отчитываю. Не моё дело заниматься воспитанием. Я пытаюсь объяснить.
Программист НЕ МОЖЕТ ЗНАТЬ заранее, потребует оно танцев или нет.
Иногда ВПЛОТЬ до последнего момента.
Это уже к тем, кто поют про катастрофическое падение квалификации.
А еще лучше НЕ СДЕЛАЛ 100% И ПОДВЕЛ КОМАНДУ, ТИМЛИДА и КОМПАНИЮ...
по крайней мере в глазах и словах менеджера и команды.
Это только говорит о проблемах современной культуры.
И надо чётко разделять: мы делаем качественный продукт или зашибаем деньгу. Во многих случаях эти цели противоположны. И не стоит страдать об одной, преследуя другую.
Это плохо сказывается на пищеварении.
Вот интересно... а это разве не Эджайл? ;)
Нет, конечно.
Agile - это криво переписанные дураками книжки восьмидесятых годов прошлого века. Если начать заниматься мифическим "agile третьего уровня", то можно и водопад получить в результате. Потому как на самом деле оно совсем не так было, как пугают молодые проповедники.
Впрочем, в той же разработке для космоса это и сейчас сделано по-человечески. Но область узкая, информация наружу практически не выходит. Только про пионерские методики Маска.
no subject
Date: 2018-08-30 11:48 am (UTC)а про грустные мысли....это о человечестве?
no subject
Date: 2018-08-30 11:53 am (UTC)\\Не решаются на уровне программиста != Не решаются
Если запамятовалось...
я начала вам оппонировать из-за вашего "программист не хочет думать".
И думаю привел достаточно рассуждений,
что есть куча возможностей,
когда резальтат не гарантирован,
сколько бы и как упорно програмисты бы не думал.
Но вам проще мЭнагерский заход -- "раз программист не решил задачу... значит он над ней не/плохо думал".
\\Я никого не отчитываю. Не моё дело заниматься воспитанием. Я пытаюсь объяснить.
1. Программист всегда виноват.
2. Если программист не виноват, см. пункт 1? %)
\\Программист НЕ МОЖЕТ ЗНАТЬ заранее, потребует оно танцев или нет.
Иногда ВПЛОТЬ до последнего момента.
\\Это уже к тем, кто поют про катастрофическое падение квалификации.
Причем тут "отсутствие квалификации" к отсутствию адекватной информации о требуемых деталях реализации?
\\А еще лучше НЕ СДЕЛАЛ 100% И ПОДВЕЛ КОМАНДУ, ТИМЛИДА и КОМПАНИЮ...
по крайней мере в глазах и словах менеджера и команды.
\\Это только говорит о проблемах современной культуры.
Нам с этим жить...
\\Agile - это криво переписанные дураками книжки восьмидесятых годов прошлого века. Если начать заниматься мифическим "agile третьего уровня", то можно и водопад получить в результате. Потому как на самом деле оно совсем не так было, как пугают молодые проповедники.
Если из личного опыта.
"Мы делаем по эджайлу (или по канбану)... но только частично",
то понятно что за этим "часично" могут скрыватся какие угодно жабы и гадюки.
Только светлая идея коммуни... эджайл тут чем виноват?
no subject
Date: 2018-08-30 12:08 pm (UTC)Постановка в кавычки текста, не соответствующего оригиналу - это уже жульничество. Тем более, если при переносе не просто изменилась формулировка, но и исказился её смысл.
1. Программист всегда виноват.
2. Если программист не виноват, см. пункт 1? %)
Может, пора закончить этот фейерверк остроумия и попробовать прочитать всё с самого начала, чтобы понять то, о чём я на самом деле пишу?
Причем тут "отсутствие квалификации" к отсутствию адекватной информации о требуемых деталях реализации?
Информация приходит. Как только программист видит, что информации не достаточно для выполнения планов или новая информация сместила планы, рапорт идёт менеджменту и менеджмент разбирается с ситуацией.
"Мы делаем по эджайлу (или по канбану)... но только частично",
то понятно что за этим "часично" могут скрыватся какие угодно жабы и гадюки.
Изначально в agile манифесте стоит, что процессы подстраиваются под потребности, а потребности под людей. Так что "частичный agile" - это самый-самый правильный, а не тот суррогат, который продают всякие жулики под маркой agile методик.
no subject
Date: 2018-08-30 12:10 pm (UTC)Программисты тоже относятся к виду homo sapiens, хотя порой попадается такое, что заставляет сомневаться во втором компоненте термина.
no subject
Date: 2018-08-30 12:20 pm (UTC)но... это уже неплохо, представьте, какой ужасающий интеллектуальный вакуум царил вокруг Галилея, да и Леонардо...
no subject
Date: 2018-08-30 12:23 pm (UTC)\\Постановка в кавычки текста, не соответствующего оригиналу - это уже жульничество. Тем более, если при переносе не просто изменилась формулировка, но и исказился её смысл.
Ну вот...
""С одной стороны, хорошо, когда все-все-все могут тестировать всё что угодно. С другой - дешевле, если разработчики будут не гонять массивные тесты после каждого маленького изменения, а думать перед тем, как что-то в коде менять.
Мечты... Мечты...""
...хотите спорить что я так уж сильно "исказил"?
Ну да... у вас тут про "больше думать, чем полагаться на тесты".
Ну так я именно ЭТОМУ и оппонирую... мысли что программисты полагаются на тесты ПОТОМУ что они такие лентяи.
А не потом что в их работе есть проблемы... для которых даже тесты (если они еще есть, в достаточном количестве и качестве), не более чем плацебо.
no subject
Date: 2018-08-30 12:28 pm (UTC)Не-а.
no subject
Date: 2018-08-30 12:28 pm (UTC)Как будь-то мЭнагер может чем-то помочь решить ситуацию ПО СУТИ.
Ну кроме как "настучать по башке нерадивому програмЁру". %)
Хотел бы я поработать в проекте,
где хотя бы на мизинец подобного счастия... или зря прошу,
желания могут и сбытса. %)))
no subject
Date: 2018-08-30 12:29 pm (UTC)Не буду настаивать
Date: 2018-08-30 12:30 pm (UTC)в стиле "мои слова значат то, что я хочу чтобы они значили".
no subject
Date: 2018-08-30 12:31 pm (UTC)Это уже отсылки к вашему личному опыту... которые мне невозможно оценить.
Re: Не буду настаивать
Date: 2018-08-30 12:31 pm (UTC)no subject
Date: 2018-08-30 12:32 pm (UTC)Задача менеджера в том и состоит, чтобы привести ресурсы в соответствие задаче.
Или задачу в соответствие ресурсам.
no subject
Date: 2018-08-30 12:46 pm (UTC)no subject
Date: 2018-08-30 01:37 pm (UTC)no subject
Date: 2018-08-30 02:04 pm (UTC)можете сравнить их кругозор, знания и ваши? их дремучий мир религиозных забобонов, домостроевских представлений о жизни? убогое образование?
no subject
Date: 2018-08-30 02:58 pm (UTC)Нашёл бы я, о чём разговаривать и чему поучиться. По крайней мере у тех предков, о которых я знаю. Люди были интересные.
no subject
Date: 2018-08-30 03:05 pm (UTC)