Прочитала Lean, в русском переводе “экономичный”, в учебнике у нас даётся как “элегантный”. И элегантный мне нравится гораздо больше. Потому что идея у автором книги появилась от “бережливого производства” Тойтоты. Но понадобилось хорошо подумать, как переложить с производства на изготовление программных систем. Где у нас вечная неопределённость и как сделать правильно сразу никто не знает. Не может знать. Очень хочется научиться делать элегантно: делать то, что нужно эффективным методом. Помним, что красиво не только потому что визуально красиво, а потому что функционально эффективно. Это ж оптимизация опять (техноэволюция, вот это вот всё). Бесконечное познание. И бесконечное стратегирование.
Показывает автор метод “Пяти почему”. На таком примере, классическом для софтверных компаний: к нам пришли клиенты с жалобами на новую версию продукта. Дальше нам надо задавать вопрос “почему” к проблеме, раскручиваю причинно-следственную связь.
- В новой версии оказалась отключена одна из опций. Почему? Потому что возникли неполадки на одном из серверов.
- Почему возникли неполадки? Потому что какая-то подсистема использовалась неправильно.
- Почему подсистема использовалась неправильно? Работавший с ней разработчик не знал, как это нужно делать.
- Почему он не знал? Потому что его не обучили.
- Почему его не обучили? Его руководитель не считает нужным обучать новых сотрудников, потому что он сам и члены его команды “очень заняты”.
Я когда читала, сначала долго смеялась, потом плакала. Потому что? Потому что про меня, про тебя и про всех нас. Пусть бросит в меня камень тот, у кого таких проблем никогда в организации не бывает.
То, что сначала выглядело как техническая ошибка, на самом деле оказалось проблемой менеджмента и организации.
Я каким-то краем уха про этот метод пяти чего-то слышала, но у меня кажется он был скорее про “пять зачем”, чтобы проверить цели/желания. Задаешь себе вопрос зачем, чтобы докопаться до настоящей неудовлетворённости.
На работе какую-то короткую диагностику багов я делаю похожим образом через уточняющие вопросы. Потому что часто приносят баг, не разобравшись в его природе. И там вроде очевидные действия не сделаны! Вот ты заводишь баг, его надо на кого-то назначить. Но надо бы на кого-то, кто сможет его починить. А что для этого надо? Надо понять в чём причина проблемы. В каком-то нормальном мире эти 5 почему себе должен задать тестировщик. Или аналитик, или кто там нам принёс этот баг. А временами не задают даже первого почему. Потом у нас баг на бек, когда он на фронтенде. Или баг на всех, когда это нереализованный функционал. И задача будет (а)синхронно пинаться от одного человека к другому. Пока не допинается до кого-то, кто в состоянии спросить ещё пару раз почему.
Возвращаясь к методологии, автор нам дал метод рационального разбора проблем. Что с этим можно делать? Для меня это выглядит как неплохая инструкция для разбора багов/инцидентов. Это такой вариант постмортема. Что я не описала? Волшебное слово на Н или К. Когда причина найдена, говорит мне моя ментальная копия Андрея (@andrei-danilian) нужно установить контроль/надзор! Но это завершающая штука. Вообще всех ещё обучить надо. Одного рассказала про классный метод не хватит. Пока прячу в корзинку “Подумать куда бы (кому и в какой момент) этот механизм можно было впихнуть для общей пользы”.
Как раз с этим завершающим этапом тоже всегда проблемы. Постмортемы пишутся (я простыни писала в своё время, со всеми объяснениями что надо сделать), сделал кто-нибудь что-нибудь чтобы починить раз и навсегда? Куда там. Вспоминается диалог из БК, в самолёте с попутчицей общается страховой агент. Он разбирает очередное ДТП. Машина загорелась, пассажиры погибли. Случилось это из-за неисправности в машине, претензия выставлена к автозаводу.
- Как вы думаете, проблемы исправят?
- Ну да, а как иначе?!
- Если стоимость урегулирования будет меньше стоимости доработок. Доработки не будет.
С багами примерно так же. Если в приоритете срочность починки, то будет заплатка, а задачи на доработку не будет. Призывы к здравому смыслу не работают.
Как сказал Питер Друкер: “Конечно же, нет ничего более бесполезного, чем эффективно делать то, что вообще делать не нужно”. Но мы всё время эффективно делаем то, что делать не нужно. Трудно точно оценить, насколько расточительна современная организация труда, но примеров вполне достаточно.
Контринтуитивная мысль. Я помню, что локальные оптимизации ведут нас не туда. Я читала Голдрата в своё время. По-этому все эти штуки, с тем что у тебя забивает товарами склад под крышу, а вам некуда продавать, я визуально легко могу представить. Сложно это переложить на наши невидимые материи. Хотя ощущение “я делаю всё что могу, чтобы хорошо и быстро сделать свою работу и в итоге никак не помогает/не влияет на то, чтобы мы отдали всю работу быстрее и лучше” со мной довольно давно. Сейчас становится лучше видно. Т.е. наверно можно сказать, что проступают фигуры из фона. Был просто хаос, теперь у этого хаоса есть объекты, которые должны менять состояния, там есть методы, есть люди. Но у меня пока гипотеза, что правильно сначала сосредоточиться на том, “что делать”, а не на том, “что не делать”. Чтобы оно хоть как-то поехало. А потом почистить можно будет. Пока на лицо дикие провалы в методах/культуре в головах.
В целом книга преждевременно классная. Она в системном менеджменте была. Но на методологию ложится отлично. Пожалуй это рассказ, как инженерный процесс должен работать в нормальном мире. Циклы обратной связи, настоящие кроссфункциональные команды из инженеров, про адекватные метрики (в противовес метрикам тщеславия), про повороты и какие они бывают, про реальность опять и попытки угадать, что в чужой голове (концепция ценности и концепция роста).