Комментарии 13
сейчас как раз подходящая система — «зима» называется. Зима + город + эти, как их, которые снег должны убирать. Годы идут, а результат аналогичный.
Исходя из логики статьи:
— есть бизнес-программист, который способен на основе стат.данных и прочей информации предусмотреть предидущей весной, что январь следующего года, побьет в ЦФО по количеству осадков всю историю прогнозов за всю историю наблюдения, а значит, надо до-закупить N снегоуборщиков и M тонн реагентов.
— тот же бизнес-программист должен спрогнозировать, что в том же январе в Чикаго впервые после открытия Америки Колмбом на улице будет минус 50 по Фаренгейту.
Скажи пожалуйста — КАК. А точнее где такие прогнозисты есть?
А теперь кейс из ИТ давайте попробуем разобрать?
— например, есть опытная софтверная фабрика, где на входе каждый год сто проектов;
— трудоемкость каждого проекта оценивает ГИП, потом сейл умножает на число Пи (включающее в себя налоги, плюс маржу, плюс риски, плюс все остальное), с итоговой суммой идёт торгуется, приносит в клюве контракт;
— идёт исполнение, выясняется что часть задач ГИПом была оценена неверно, что часть задач была описана на недостаточном уровне детализации, что позволило заказчику переобуться и расширить требования, что часть задач вообще делать не надо, но вместо них надо другое и т.п. все исполнители ведут учет рабочего времени, все шиты заполнены, экономика считается регулярно и т.п.
— тут важно: на входе уже есть ТЗ, заказчику не нужен прототип завтра, а потом послезавтра +1 фича, а послезавтра +2 фичи; ему нужен ко времени Ч полностью готовая система с полным функционалом, готовая к ПСИ, развертыванию в опытную, с переездом данных и в продуктив; это я к тому, что заказчику пофиг, хоть по скрам, хоть вотерфолл, но вот прямо сейчас и железа нет, чтобы ваш прототип крутить, и людей в заказчике чтобы смотреть — сделайте и в конце покажите;
Проблема: по результатам года работы фабрики, год за годом одно и то же: ряд проектов в глубоком убытке, ряд других в хорошем плюсе. Общее сальдо вроде положительное -)
Вопрос: какой процесс или какой бизнес-программист позволит увеличить число прибыльных и снизить число убыточных?
какой процесс или какой бизнес-программист позволит увеличить число прибыльных и снизить число убыточных?
любой приличный. В вашем описании уже явно присутствует стратификация систем. Очевидно, что результат проекта зависит от их сочетания.
Например, частями системы может быть Заказчик (не конкретный, а некий его тип), ГИП (если он не один), сейл (опять же, если он не один), команда, применяемый подход (если вы их перечислили не просто так — скрам, водопад).
Каждый проект выполняется какой-то комбинацией частей системы. Есть комбинации удачные, есть — так себе.
Соответственно, можно выявить зависимости, тем же регрессионным анализом или просто построив график точек в экселе. Главное — разбить обе системы (объект и субъект) на части и посмотреть, какая из частей оказывает негативное влияние.
У вас прекрасная ситуация, чтобы потренироваться. Когда все проекты успешны, или наоборот — плохи, хрен поймешь, что надо делать — приходится с потолка брать изменения, вносить в систему и смотреть, что получится. А у вас уже есть успешные примеры, значит — надо просто понять, какие именно факторы приводят к успеху.
Системный анализ определяет что мы сами и все окружающее нас, в одно и то же время является Системой, и является Элементом системы более высокого порядка.
Город это очень сложная система, с тысячами внутренних процессов. До тех пор пока мы рассматриваем горд как Систему — все ОК, все процессы могут быть модифицированы в целях качества, скорости, или любого иного нужного нам показателя. Но сразу после того как мы начинаем рассматривать город как Элемент системы более высокого порядка — управляемость падает минимум на порядок. Город как элемент Государства вынужден подстраиваться под те процессы, которые диктует ему Государство. Город как элемент системы Климат — подстраивается под процессы диктуемые Климатом.
Это к вопросу к уборке снега в этом году. Город на своем уровне — делает все что может. Но процессы бюджетирования и закупок спущенные с уровня Государства (элементом которого он является) не позволяют ему хоть сколько-нибудь оперативно реагировать на изменения произошедшие в процессах системы Климат (как качественно, так и количественно).
Ровно то же самое и с моим кейсом из ИТ:
Софтверная фабрика это Система, со своими процессами, контролем и т.п., до тех пор пока мы рассматриваем фабрику как «сферическую систему в вакуме» — все отлично, мы можем достичь безумно высоких KPI (это к историям Ивана про отделы логистики, склад, поддержки пользователей, которые замкнуты на внутреннего потребителя, или группу внутренних процессов, или внешние неизменяемые процессы, где действительно грамотный бизнес-программист может выстроить наиболее эффективную модель).
Но как только мы начинаем рассматривать фабрику как элемент Системы более высокого порядка — мы начинаем жить в условиях подчиненности и неопределенности, до тех пор пока точно не узнаем, а по каким именно законам живет система верхнего порядка. Фабрика являясь сама по себе здоровой Системой, например котёнком, по отношению к системам высокого порядка становится слепым котенком, непонимающим откуда ждать очередного пинка, снега, или молока.
Котенок очень в ограниченных случаях может прогнозировать действий Человека (как системы более высокого порядка). Котенок в принципе не представляет себе что такое Город (как система), а уж про Государство и вовсе не поймет даже если начать объяснять. Меж тем, завтра Государство может издать закон об обязательной кастрации всех котов, на который ни Город, ни Человек, ни тем более котенок никак не могли повлиять, а иной раз даже предположить.
Сколько стоило исполнение пакета законов Яровой для телеком-рынка? Конкретно для каждого оператора большой тройки? Для городского телеком-оператора? Для районного провайдера? Этот пакет законов свалился для исполнения весьма неожиданно, я помню реакцию рынка, все охренели, а некоторые даже не поверили в такой абсурд. Государство, как система высшего порядка по отношению к своим элементам — телеком-провайдерам и прочим игрокам рынка — навязала и обязала всех их исполнить то что требуется ему.
И никакой бизнес-программист, который находится на уровне Элемента, не способен предположить что там завтра придумаеточередная яровая Система высшего порядка.
В кейсе про фабрику главное заключается в том, что можно со 100% эффективностью выстроить процессы внутри. Но как только эта фабрика получит навязанное требование об изменении снаружи, которое никто не в состоянии предусмотреть, модель ее существования изменится при исполнении такого требования.
Другими словами — я верю Бизнес-программиста способного менять что угодно внутри той Системы, где находится он сам, ну чо там склад автоматизировать, делов-то. Но как только мы начинаем говорить о внешнем мире — Бизнес-программист разводит руками и оказывается не у дел.
Город это очень сложная система, с тысячами внутренних процессов. До тех пор пока мы рассматриваем горд как Систему — все ОК, все процессы могут быть модифицированы в целях качества, скорости, или любого иного нужного нам показателя. Но сразу после того как мы начинаем рассматривать город как Элемент системы более высокого порядка — управляемость падает минимум на порядок. Город как элемент Государства вынужден подстраиваться под те процессы, которые диктует ему Государство. Город как элемент системы Климат — подстраивается под процессы диктуемые Климатом.
Это к вопросу к уборке снега в этом году. Город на своем уровне — делает все что может. Но процессы бюджетирования и закупок спущенные с уровня Государства (элементом которого он является) не позволяют ему хоть сколько-нибудь оперативно реагировать на изменения произошедшие в процессах системы Климат (как качественно, так и количественно).
Ровно то же самое и с моим кейсом из ИТ:
Софтверная фабрика это Система, со своими процессами, контролем и т.п., до тех пор пока мы рассматриваем фабрику как «сферическую систему в вакуме» — все отлично, мы можем достичь безумно высоких KPI (это к историям Ивана про отделы логистики, склад, поддержки пользователей, которые замкнуты на внутреннего потребителя, или группу внутренних процессов, или внешние неизменяемые процессы, где действительно грамотный бизнес-программист может выстроить наиболее эффективную модель).
Но как только мы начинаем рассматривать фабрику как элемент Системы более высокого порядка — мы начинаем жить в условиях подчиненности и неопределенности, до тех пор пока точно не узнаем, а по каким именно законам живет система верхнего порядка. Фабрика являясь сама по себе здоровой Системой, например котёнком, по отношению к системам высокого порядка становится слепым котенком, непонимающим откуда ждать очередного пинка, снега, или молока.
Котенок очень в ограниченных случаях может прогнозировать действий Человека (как системы более высокого порядка). Котенок в принципе не представляет себе что такое Город (как система), а уж про Государство и вовсе не поймет даже если начать объяснять. Меж тем, завтра Государство может издать закон об обязательной кастрации всех котов, на который ни Город, ни Человек, ни тем более котенок никак не могли повлиять, а иной раз даже предположить.
Сколько стоило исполнение пакета законов Яровой для телеком-рынка? Конкретно для каждого оператора большой тройки? Для городского телеком-оператора? Для районного провайдера? Этот пакет законов свалился для исполнения весьма неожиданно, я помню реакцию рынка, все охренели, а некоторые даже не поверили в такой абсурд. Государство, как система высшего порядка по отношению к своим элементам — телеком-провайдерам и прочим игрокам рынка — навязала и обязала всех их исполнить то что требуется ему.
И никакой бизнес-программист, который находится на уровне Элемента, не способен предположить что там завтра придумает
В кейсе про фабрику главное заключается в том, что можно со 100% эффективностью выстроить процессы внутри. Но как только эта фабрика получит навязанное требование об изменении снаружи, которое никто не в состоянии предусмотреть, модель ее существования изменится при исполнении такого требования.
Другими словами — я верю Бизнес-программиста способного менять что угодно внутри той Системы, где находится он сам, ну чо там склад автоматизировать, делов-то. Но как только мы начинаем говорить о внешнем мире — Бизнес-программист разводит руками и оказывается не у дел.
выясняется что часть задач ГИПом была оценена неверно
Если из года в год задачи оцениваются неверно, может стоит посмотреть на того кто их оценивает и почему идет провал по ним? Т.е. вести работу над ошибками. Сомневаюсь, что есть люди, которые один проект оценили успешно, а второй нет, а если и так, то может это был не их «профиль». Тогда, возможно, стоит изучить вопрос и найти слабые\сильные стороны у «оценщиков» и давать им проекты по их сильным сторонам.
часть задач была описана на недостаточном уровне детализации
Тут вопрос — почему. Выясняешь почему, говоришь с человеком, выясняешь причины, учишь (ругать — исключение, если он постоянно неверно делает оценку, напираясь на те же грабли).
Ему нужен ко времени Ч полностью готовая система с полным функционалом
На заказной разработке тем и выгодно, что ты можешь закончить обговаривать что именно нужно заказчику, подписать договор, далее делать. И у тебя будет дедлайн. Если ты к нему не можешь физически выполнить задачу, зачем её брать? Я понимаю, тут многое не от вас конкретно зависит, а от руководства, но наверное им как раз и надо показывать эти ежегодные результаты с глубоким исследованием вопроса. Иначе и правда ничего не будет меняться из года в год.
Если из года в год задачи оцениваются неверно, может стоит посмотреть на того кто их оценивает и почему идет провал по ним?
Процент неверное оцениваемых задач колеблется от 10 до 20, однако, стоит учесть, что неверная оценка это не только дефицит, но и профицит. Дефицит дает убыток, профицит снижает шанс взять контракт но и дает доп.прибыль.
Вопросов к эффективности ГИПов — нет, на том уровне абстракции на котором работает фабрика, ГИПы совершают подвиг, давая 80% валидных оценок.
Тут вопрос — почему. Выясняешь почему, говоришь с человеком, выясняешь причины, учишь (ругать — исключение, если он постоянно неверно делает оценку, напираясь на те же грабли).
Почему на входе бывают задачи с высоким уровнем абстракции? Да потому что они приходят с внешнего рынка, заказчик считает что проработка ТЗ достаточна, и ты либо вынужден с ним соглашаться, либо отказываться от контракта. В этом гигантская пропасть в работе на внешнего заказчика и внутреннего. Как по мне, так те кто работают на внутреннего — делают это в тепличных условиях и правды жизни не нюхали :-) и именно программисты работающие на внутреннего заказчика придумали от безделия эти спринты с релиз-прототипами каждую неделю (ох и нахватаю я наверное сейчас), просто потому что программистам работающих на внешнем рынке некогда — они хреначат и хреначат, ровно в тех условиях, которые им продиктовал внешний рынок.
Если ты к нему не можешь физически выполнить задачу, зачем её брать?Затем, что вынужден брать, иначе будет нечего есть. Выбирать что брать, а что нет, можно только до тех пор пока сыт. Как только ты понимаешь, что через полгода у тебя будет кассовый разрыв, то и действовать начинаешь соответсвенно — чуть больше рисковать, брать то за что еще месяц назад даже не взглянул-бы, именно поэтому появляются задачи с высоким уровнем абстракции и начинается тяни-толкай с заказчиком — вот это требование мы реализуем ровно как говорите вы, но взамен вот это требование то как видим сами (а значит с минимумом работы). В этом случае искусство коммуницирования в рамках управления составом работ становится первично-важным навыком менеджера.
Все это конечно хорошо, но не хватает описания необходимых и достаточных условий, при которых оно будет работать.
Ага, бизнес-программист не пойдет работать туда, где нет необходимых условий. Мой вопрос вот в этом — каковы это условия?
Вот еще одна хорошая книга по системному мышлению.
Жаль, что у меня нет плюсомёта, в хорошем понимании этого словосочетания.
Отличная статья. Доступно рассказано о методах (сам люблю использовать наблюдение) сбора информации и их влиянии на систему.
Отличная статья. Доступно рассказано о методах (сам люблю использовать наблюдение) сбора информации и их влиянии на систему.
Как-то однобоко вы подошли к рассуждению об «эмерджентных» свойствах, сделав акцент на наблюдении за работой системы. А ведь это совсем не популярный и далеко не самый практичный метод системного анализа, просто потому что не всегда возможно провести натурный эксперимент!
Чтобы «понять» систему, действительно, мало её «разобрать» на составные части (собственно, в этом и заключается анализ — в понимании функций отдельных элементов), затем нужно её «собрать» заново (и этот процесс уже называется синтезом — понимании взаимосвязей между элементами). Для понимания системы куда чаще используется моделирование, будь то математическое, описательное, визуальное, имитационное и т.д.
К слову, дедукция не про понимание целого по частям, дедукция в классической трактовке — умение делать частные умозаключения на основе общего понимания.
Чтобы «понять» систему, действительно, мало её «разобрать» на составные части (собственно, в этом и заключается анализ — в понимании функций отдельных элементов), затем нужно её «собрать» заново (и этот процесс уже называется синтезом — понимании взаимосвязей между элементами). Для понимания системы куда чаще используется моделирование, будь то математическое, описательное, визуальное, имитационное и т.д.
К слову, дедукция не про понимание целого по частям, дедукция в классической трактовке — умение делать частные умозаключения на основе общего понимания.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мужчина, pause on caught exceptions