Comments 26
https://www.lesswrong.com/posts/GZSzMqr8hAB2dR8pk/studies-on-slack
Пересказывать статью не хочу, потому что там очень тонко, важно и точно.
Для меня эта статья определила всё. Я не хочу работать там, где нет stress (не понятно что делать). Я не хочу работать там, где нет slack (где точно ясно что делать и максимальная эффективность).
Баланс stress & slack - залог во-первых самореализации и самоактуализации (простите, мне личные ценности важнее корпоративных), во-вторых для компании обеспечивает запас устойчивости в случае смены требований.
Ссылка интересна, но ее связь с текстом явно не просматривается.
Сделайте шаг на верх.
Статья про value stream и kpi, из которого предполагается оптимизация. Оптимизация - это стресс. Чистый стресс без slack помогает в коротком забеге и мешает в долгом. См ссылку.
В тексте не затрагивается этическая, политическая или экономическая сторона вопроса. Равно как и вопросы оптимизационной функции или предпосылки старта проекта не рассматриваются. И теория игр не затрагивается. Если обобщать, то до Big Bang, как до исходной точки можно добраться.
Вы хотите фокусироваться только на реализации технологии, а я - на последствиях.
Отличное желание. Пишите свою статью.
Но она вряд ли будет в тематике хабра. Психология, социология, политология, .... но не техника.
Фокусироваться здесь на последствиях — превратить все в холивар. Вы же это прекрасно понимаете сами.
А в чем смысл всего вот этого без экономической стороны вопроса? Ну вот реально, вы скажем пишете: «Не исключены возвраты на доработку или отказы от проведенных доработок.», причем выглядит это так, будто это что-то плохое. А по мне — так нормальная часть работы, любой работы, включающей хоть немного R&D, т.е. такой, где результат хоть немного непредсказуем (и в общем-то, именно от такой обычно можно получить неожиданно большой профит, рутина как правило такого не дает). И иногда отказ от проведенных доработок — это самое лучшее, что можно сделать. Выкинуть без жалости, и двигать дальше, с учетом полученных в процессе новых знаний.
Потому что экономическая сторона вопроса -- артефакты конкретного проекта.
И на общественное обсуждение это выносится в редких случаях.
Xsolla, например, была у всех на слуху.
Не путайте инструменты и объективные артефакты со списоком предпринимаемых потом мер. Четкая картинка может помочь принять взвешенное решение. В тумане точно шашкой не так махать будете.
Откуда такое постоянное желание все мешать в кучу. "А вдруг, а что если, иногда бывает, а как быть .... ". Декомпозируйте сложную задачу, а потом синтезируйте.
Очевидно же.
Вот у нас тоже есть целый отдел, который пытается подобными же вещами заниматься. Например, измерять и прогнозировать (на базе Jira и Git) скажем Lead Time по задачам. Получается у них откровенная хрень, прямо скажем. Ну вот яркий пример — если я занимался задачей скажем два дня, 1 января и 30 июня, то они считают, что делал я ее полгода. То есть, статусы «отложено» не учитываются.
У них есть в голове некая модель, пригодная для процесса, где R&D не пахнет, где каждый день тупая одинаковая рутина, и взяв задачу в работу, надо ее непременно закончить сразу — а тянуть полгода нехорошо.
Тогда как в реальной жизни задача имеет самый низкий приоритет, и польза от нее минимальна. И смысла Lead Time по ней считать — никакого. И вот это все откуда проистекает? А из простой вещи — ни в Jira, ни в Git нет информации о полезности задач (ну и коммитов). Уж как ни посмотрите — хоть экономической, хоть какой. И если у вас все задачи одинаково (бес)полезны — на выходе из подобных расчетов чаще всего выходит нечто бессмысленное, на основе чего принимать какие-либо решения просто нельзя.
Заметьте, я не хочу сказать ничего плохого про саму идею. Всю жизнь старался подобные метрики снимать, и выводы из них делать, и жиру с гитом связывать. Я скорее о другом — что метрики, особенно лежащие на поверхности, обычно годятся только для проекта, состоящего из тупой рутины. А в проекте другого типа могут оказаться вредными.
Если серьезно и без клоунского колпака.
Вы все верно говорите. Об этом и статья. Считать нужно очень аккуаратно и поднимать все трейсы и переходы. Классические консалтеры не очень хорошо понимают нюансы DevOps и морозят нелепицы.
Инструмент Process Mining позволяет построить реальную картину, это как туннельный микроскоп. Туда люди с экселем или табло не заберутся никогда.
Вынесение суждений и заключений -- отдельный сложный процесс. Человеку, который никогда не занимался серьезной разработкой будет крайне тяжело объективно оценить даже фактические метрики. Равно как и обсуждение нюансов того или иного проекта никак невозможно в коментах хабра по многим причинам. Здесь только вершина айсберга, даже не 1/10.
Если же наверху будет принято внедрять VSM, то самое лучшее, что можно сделать разработчикам -- самим курировать этот процесс с пониманием технологий, приводящих к объективным показателям.
Стиль хабра редко предполагает серьезные дискуссии. Все обычно сваливается в потенциальную яму. Невысокий заборчик помогает крайне редко.
Вот как это все выглядит. Вы пришли, стали навязывать свою точку зрения в комментариях. Попытка аккуратно выправить ситуацию не очень помогла (на верх, кстати, пишется слитно). Несогласие с Вашими замечаниями вызвала обиду и опускание пальцем где дотянулись. С учетом Ваших 207 публикаций и уже накопленного опыта это выглядит очень странно.
Правда ведь?
Зачем так поступать?
Какова цель?
Прочитал только что на реддите историю как раз в тему, про оптимизацию рабочих процессов.
Посетитель кафе уронил ложку под стол. К нему тут же подскакивает официант и достает из нагрудного кармана новую. Посетитель очень впечатлен и спрашивает официанта, как ему удалось принести ложку так быстро. На что официант отвечает, что команда экспертов по эффективности персонала собрала и обработала огромный объем данных и пришла к выводу, что ложки роняют 11.4% посетителей, и если официанты всегда будут носить ложку с собой, это позволит сэкономить 7.4 минуты рабочего времени за смену.
Посетитель ещё больше впечатлен, и спрашивает, какие ещё оптимизации были внедрены. Официант показывает белую верёвочку, которая торчит из застегнутой ширинки. Расстегнув ширинку и потянув за верёвочку, он может посетить туалет не трогая ничего руками, и таким образом сэкономить 45 секунд на мытье рук.
Посетитель снова восхищается, но потом задумывается, и смущённо спрашивает официанта, что достать-то он все достал без рук в туалете, но как потом обратно в штаны засунуть не трогая руками? На что официант с широкой улыбкой отвечает, "Ну а ложка-то на что?"
Так что да, оптимизация и дата майнинг - это страшная сила!
Угу.
Трактат о морально-этических характеристиках белого листа бумаги. Если хотите ездить не по заезженным дорожкам, отступите в сторону. Почитайте книги и статьи по process mining, разберитесь в алгоритмах fuzzy miner, split miner, alpha miner… флёр слетит моментально.
Там действительно интересно. А ложечки и верёвочки пусть в желтой прессе остаются.
Разработчики и колпак