В дебрях водопада
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 такой подход - это стандарт. Не в том смысле, что инженеры могут доказать в числах неизбежность будущих проблем, а в том, что менеджмент учитывает риски и не боится с ними работать.
Вплоть до сворачивания невыполнимых проектов на ранних фазах.
