заметки: ускорение инженерных работ
Первый шаг ускорения: сомневаться в запросах(requirements/требованиях/необходимостях/потребностях), и вообще, что нужно делать, а что нет.
- первое, что можно сделать, поставить напротив каждого требования/запроса, имя того, кто это запросил. Чтоб запрос был не "вообщешный": от "отдел"а, или "попросили", а кто-то конкретный. Чтоб можно было пойти к этому человеку, уточнить что он имел в виду. Используем принцип почтальона.
- далее уже можно ставить под сомнение то, что вообще это нужно делать. Несмотря на ум человека, и возможно, даже мнение об уме человека может оказаться самым опасным, т.к. из-за этого мнения, запросы этого человека не будут проходить проверку.
- Далее эти запросы можно уточнять, либо делать менее идиотскими, тупыми, более адекватными.
Второй шаг: удалять все части процесса, элементы, которые возможно будет удалить.
- удалять любую часть процесса, элемента, которую можем. https://www.corporate-rebels.com/blog/the-art-of-subtraction
Musk: "You may have to add [parts or processes] back later. In fact, if you do not end up adding back at least 10% of them, then you didn't delete enough."
То есть, Маск за то, чтоб удалять чем больше людей, тем больше - добавить всегда сможем.
если в итоге, мы не добавили как минимум 10% из этого, значит можно еще удалять, и удалили недостаточно.
Третий шаг: Упростить, оптимизировать.
упрощаем, оптимизируем то, что осталось. Почему именно этот шаг третий: чтоб не оптимизировать то, что должно быть не только оптимизировано, но и существовать в принципе. Поэтому первыми двумя шагами, мы избавляемся от того, что ненужно делать, а то что решили все-таки взять в работу, упрощать и оптимизировать - этот порядок важен.
Четвертый шаг: Ускорение времени цикла
Ускорение процессов. Думать, как ускорять эти процессы. Но только те, процессы, которые прошли первые 3 шага. Потому что можно ускорить совсем то, что не должно было вообще существовать.
После всей проделанной работы:
- уточнения полезности требований, запросов, идей(сомнении в них и удалении тупых, формулирование более полезных)
- удаления всех возможных процессов, элементов
- упрощения и оптимизации процессов
- ускорении(опять же упрощении, удалении)
- можно приступать, думать об автоматизации этих шагов: как можно автоматизировать их.
Иначе мы будем думать про автоматизацию того(что будет требовать ресурсов), что вообще не должно было быть в целом сделано, а после и автоматизировано.
Применять эти шаги не только в одной области, но в бюджетировании, планировании, стратегировании, оказании услуг, в самом продукте.
Пример с ШСМ может быть: «Упрощаем способы стать умнее». Процесс может быть усложнен, но результаты получаются качественнее и быстрее. Хотя, можно много что убирать, удалять, упрощать, ускорять тоже.
Нужно попробовать такое в курсе.
Кроме этого: T-Shape профессионалы.
Менеджерам нужно знать, инженерно, то, с чем они работают. Иметь не только менеджерские знания, но и насколько возможно, глубокие предметные знания.
Возражением может быть: «нельзя все выучить, узнать.»
Да, и нет. Можно научиться учиться быстрее, глубже, эффективнее, что будет держать человека на плаву эффективности, несмотря на динамику изменений в мире. По крайней мере, человек будет оставаться в какой-то степени адекватным. Если менеджер не умеет учиться, погружаться в детали, это будущая проблема организации, его можно увольнять, и нанимать того, кто умеет. Так как неадекватным менеджер ухудшает результаты своими решениями, которые он принимает на основе своих далеких от соответствия к реальности представлениями.
https://www.corporate-rebels.com/blog/musks-algorithm-to-cut-bureaucracy
https://www.linkedin.com/pulse/applying-elon-musks-algorithm-software-engineering-marko-marinovic-laudf/