В дебрях водопада

[vit_r]

Ликбез по поводу комментария gineer, который не хочет регистрироваться на DW.

Удивительно, что мне приходится это писать, но всё-таки придётся озвучить совершенно базовые принципы, которые принимаются как аксиомы для всего, что я пишу на тему IT.

1. Не все проблемы решаются на уровне программиста.

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

3. Не все проблемы решаются в тот момент, когда они обнаружены.

Дальше следуют совсем элементарные вещи типа "Не все проблемы надо решать", но остановлюсь на трёх.

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

Что принято делать в такой ситуации?

Брать бубен и танцевать.

Что надо делать?

Передавать ответственность менеджеру.

Да, сюда может входить решение "выбросить код и переписать всё заново". И, да, я видел, как такое решение принималось в реальном проекте.

Естественно, это редкие светлые моменты посреди тёмного царства. Но они бывают.

Что делать, если решение проблемы маловероятно в ограничениях бюджета?

Стандартное решение: поменять критерии качества и загнать программистов в переработки. Естественно, не оплачиваемые.

Основная причина того, почему я ушёл из менеджмента, это типичный паттерн: "Менять ничего нельзя! Денег больше не будет! Надо сделать вчера. Мотивируй людей, чтобы они сделали быстро и качественно. Ты менеджер. Это твоя обязанность."

Да, бывает и по-другому. В том числе я видел как меняли сроки, добавляли людей, покупали тулы. И постановку задачи тоже меняли.

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

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

Естественно, далеко не везде. Культура уходит, но она всё ещё жива.

Третий аспект самый замечательный: "Машина мчится по серпантину. Педаль газа заклинило. Тормоза не работают. Что будешь делать?"

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

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

И в большинстве случаев ответ был совершенно стандартный.

Но на моём профессиональном пути встречался и адекватный менеджмент, который не впадал в панику, а принимал меры.

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

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

Вплоть до сворачивания невыполнимых проектов на ранних фазах.

Comments

[12_natali]

любопытно, что он и с вами успел активно пообщаться, со мной уже, кажется, 3-и сутки без остановки:). похоже, человек в отпуске и скучает.

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

У ВАС не картина мира

[gineer.livejournal.com]

а булшет с мракобесием и невежество ими погоняет.

Re: У ВАС не картина мира

[vit_r]

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

[vit_r]

Человек совершенно типичен для программиста. Как взглядами, так и наличием времени.

Свои самые длинные дискуссии я вёл, когда интенсивно разрабатывал на том же С++. Потому что компиляция проекта долгая. Ждать просто так лень. Да и ошибки, пойманные в тестах, ставят под сомнение веру в человечество - надо как-то отвлекаться от грустных мыслей.

[12_natali]

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

а про грустные мысли....это о человечестве?

[vit_r]

а про грустные мысли....это о человечестве?

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

[12_natali]

ну, да, ничего не поделаешь, пока уровень человечества - 15% людей осознанных, остальные....ведомая масса.
но... это уже неплохо, представьте, какой ужасающий интеллектуальный вакуум царил вокруг Галилея, да и Леонардо...

[vit_r]

Разум не развивается в вакууме. Также как и драматурги вокруг Шекспира, окружение упомянутых гениев было вполне на уровне.

[12_natali]

да, конечно, но я говорю об их % по отношению ко всему населению. для простоты - ваши/мои пра-пра могли бы быть серьезными собеседниками, скажем, в вашем блоге?

[vit_r]

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

[12_natali]

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

[vit_r]

Ой. Поговоришь с российским профессором - встретишь дремучий мир имперских заскоков.

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

[12_natali]

значит, вам повезло.

[gineer.livejournal.com]

1. Я приводил примеры только тех, которые на уровне программиста -- меня.
Вы меня там отчитали, за то что "слишком личное",
а теперь тут отчитываете... уже за то... а за что собственно?


2. Это проблема? Или такое ПОЗИТИВНОЕ решение?
В стиле Карлсона "Пустяки! Дело то житейское". %)


3. Гм... я вроде где-то чему-то подобному оппонировал?


""Программисту поставили задачу - он не может её решить или решение требует танцев с бубнами.

Что принято делать в такой ситуации?

Брать бубен и танцевать.

Что надо делать?

Передавать ответственность менеджеру.""

Программист НЕ МОЖЕТ ЗНАТЬ заранее, потребует оно танцев или нет.
Иногда ВПЛОТЬ до последнего момента.

А таски... часто имеют свойство сделал на 99% == не сделал на 100%
А еще лучше НЕ СДЕЛАЛ 100% И ПОДВЕЛ КОМАНДУ, ТИМЛИДА и КОМПАНИЮ...
по крайней мере в глазах и словах менеджера и команды.


\\Да, сюда может входить решение "выбросить код и переписать всё заново". И, да, я видел, как такое решение принималось в реальном проекте.

И я... и не просто видел, а и участвовал.
Бьешь себя в грудь коленом, извиняешся,
что мол вот так, переоценил свои силы и т.п. %)


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


Вот интересно... а это разве не Эджайл? ;)
Что надо мол мелкие итерации, взиамодействие с заказчиком, стендапы с разработчиками...


\\Вплоть до сворачивания невыполнимых проектов на ранних фазах.

Спасибо за лучик света в темном царстве.

[vit_r]

Я приводил примеры только тех, которые на уровне программиста -- меня.

Не решаются на уровне программиста != Не решаются

а теперь тут отчитываете...

Я никого не отчитываю. Не моё дело заниматься воспитанием. Я пытаюсь объяснить.

Программист НЕ МОЖЕТ ЗНАТЬ заранее, потребует оно танцев или нет.
Иногда ВПЛОТЬ до последнего момента.

Это уже к тем, кто поют про катастрофическое падение квалификации.

А еще лучше НЕ СДЕЛАЛ 100% И ПОДВЕЛ КОМАНДУ, ТИМЛИДА и КОМПАНИЮ...
по крайней мере в глазах и словах менеджера и команды.

Это только говорит о проблемах современной культуры.

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

Это плохо сказывается на пищеварении.


Вот интересно... а это разве не Эджайл? ;)

Нет, конечно.

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

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

[gineer.livejournal.com]

\\Я приводил примеры только тех, которые на уровне программиста -- меня.
\\Не решаются на уровне программиста != Не решаются

Если запамятовалось...
я начала вам оппонировать из-за вашего "программист не хочет думать".

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

Но вам проще мЭнагерский заход -- "раз программист не решил задачу... значит он над ней не/плохо думал".


\\Я никого не отчитываю. Не моё дело заниматься воспитанием. Я пытаюсь объяснить.

1. Программист всегда виноват.
2. Если программист не виноват, см. пункт 1? %)


\\Программист НЕ МОЖЕТ ЗНАТЬ заранее, потребует оно танцев или нет.
Иногда ВПЛОТЬ до последнего момента.
\\Это уже к тем, кто поют про катастрофическое падение квалификации.

Причем тут "отсутствие квалификации" к отсутствию адекватной информации о требуемых деталях реализации?



\\А еще лучше НЕ СДЕЛАЛ 100% И ПОДВЕЛ КОМАНДУ, ТИМЛИДА и КОМПАНИЮ...
по крайней мере в глазах и словах менеджера и команды.
\\Это только говорит о проблемах современной культуры.

Нам с этим жить...


\\Agile - это криво переписанные дураками книжки восьмидесятых годов прошлого века. Если начать заниматься мифическим "agile третьего уровня", то можно и водопад получить в результате. Потому как на самом деле оно совсем не так было, как пугают молодые проповедники.

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

Только светлая идея коммуни... эджайл тут чем виноват?

[vit_r]

я начала вам оппонировать из-за вашего "программист не хочет думать".

Постановка в кавычки текста, не соответствующего оригиналу - это уже жульничество. Тем более, если при переносе не просто изменилась формулировка, но и исказился её смысл.


1. Программист всегда виноват.
2. Если программист не виноват, см. пункт 1? %)

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


Причем тут "отсутствие квалификации" к отсутствию адекватной информации о требуемых деталях реализации?

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

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

Изначально в agile манифесте стоит, что процессы подстраиваются под потребности, а потребности под людей. Так что "частичный agile" - это самый-самый правильный, а не тот суррогат, который продают всякие жулики под маркой agile методик.

[gineer.livejournal.com]

\\я начала вам оппонировать из-за вашего "программист не хочет думать".

\\Постановка в кавычки текста, не соответствующего оригиналу - это уже жульничество. Тем более, если при переносе не просто изменилась формулировка, но и исказился её смысл.

Ну вот...

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

Мечты... Мечты...""

...хотите спорить что я так уж сильно "исказил"?

Ну да... у вас тут про "больше думать, чем полагаться на тесты".

Ну так я именно ЭТОМУ и оппонирую... мысли что программисты полагаются на тесты ПОТОМУ что они такие лентяи.

А не потом что в их работе есть проблемы... для которых даже тесты (если они еще есть, в достаточном количестве и качестве), не более чем плацебо.

[vit_r]

у вас тут про "больше думать, чем полагаться на тесты".

Не-а.

Не буду настаивать

[gineer.livejournal.com]

но это уже какие-то СОВСЕМ тонкие модальности...

в стиле "мои слова значат то, что я хочу чтобы они значили".

Re: Не буду настаивать

[vit_r]

Естественно, мои слова несут тот смысл, который я в них вкладываю.

[gineer.livejournal.com]

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

Как будь-то мЭнагер может чем-то помочь решить ситуацию ПО СУТИ.
Ну кроме как "настучать по башке нерадивому програмЁру". %)

Хотел бы я поработать в проекте,
где хотя бы на мизинец подобного счастия... или зря прошу,
желания могут и сбытса. %)))

[vit_r]

Как будь-то мЭнагер может чем-то помочь решить ситуацию ПО СУТИ.

Задача менеджера в том и состоит, чтобы привести ресурсы в соответствие задаче.

Или задачу в соответствие ресурсам.

[gineer.livejournal.com]

\\а не тот суррогат, который продают всякие жулики под маркой agile методик.

Это уже отсылки к вашему личному опыту... которые мне невозможно оценить.