Comments 11
```
было a. a было не b.
нужно i.
это не x. это y.
в результате - f. надежно. уверенно. четко.
хотите чтобы я g? могу сделать так, чтобы u.
```
спасибо за очередной рецепт свиных крылышек!
Нет, я конечно понимаю. Но статья сухая и из-за этого не всем 100% понятная. Но уже куда лучше такая статья, чем отсутствие какой-либо на данную тему.
Огромное спасибо за статью, ведь писать статьи сложно дополнительно к основной работе.
Ну без обид, но статья ни о чём.
Суть любого совещания в том, чтобы обсудить проблему, предложить пути решения и выбрать оптимальный вариант. Если специалисты собираются, чтобы тупо поболтать и пожаловаться, ничего не предлагая, то стоит задуматься, а нужны ли такие спецы. Ну или претензия к лиду.
По сути в статье написали, что для того, чтобы повысить производительность, нада начать РАБОТАТЬ. Кто бы мог подумать.
Согласен, сами по себе, совещания, нормальный инструмент.
Проблема возникает, когда решения не фиксируются или могут пересматриваться без ограничений.
В этот момент встреча перестает быть точкой принятия решения и становится частью бесконечного процесса обсуждения.
В статье скорее про это.
Не "не нужно общаться", а "система должна ограничивать, где обсуждение заканчивается".
Не "система должна". Тут не так далеко была статья про перекладывание ответственности, когда виноваты все в целом. Есть спецы, которые получают за это деньги, если бы в их обязанности входило собраться и поболтать о том, как всё не работает, то проще на их место перевести охранника или уборщицу, выхлоп будет тот же за меньшие деньги. А тут люди, в чьи обязанности входит закрыть проект в срок не могут разобраться и решить, как это делается. Ну и не ясно, зачем нужен лид, который собирает всех на поговорить, но не принимает никаких организационных решений. Проблема как всегда не в системе. Самая забагованная часть компа всё так же по нашу сторону и напротив экрана. Вы сами выводы написали, что для всего требуется расставить приоритеты, принять решение, контролировать. Собственно обязанности Лида, который опять же не хотел работать и контролировать свой детский сад.
Тут на самом деле нет противоречия.
Сильный лид действительно должен:
расставлять приоритеты
принимать решения
держать фокус
Вопрос в другом: как именно он это делает. Если всё держится на том, что:
лид постоянно собирает всех
вручную разруливает
каждый раз заново объясняет приоритеты
То это работает, но плохо масштабируется
В какой-то момент система начинает зависеть не от процесса, а от того, "насколько сегодня включен конкретный человек". И именно тогда:
растёт количество встреч
решения начинают плавать
команда живёт от разговора к разговору
То, что я называю системой в статье, это как раз способ не убрать ответственность с лида, а зафиксировать его решения в виде правил. Чтобы:
приоритеты не пересобирались каждый раз
решения не откатывались
команда не зависела от последнего созвона
По сути: слабый лид компенсирует хаос встречами, в то время как сильный сначала принимает решения, а потом делает так, чтобы их не нужно было обсуждать заново.
Система, если она не автоматизированная, всегда зависит от "состояния человека". Иначе и быть не может. Вот сегодня есть желание работать, а завтра нет, и система из состояния "рабочая" может перейти в состояние "не рабочая". Это человеческий фактор. Хотя с точки зрения процесса всё может быть как обычно.
Исходить из процесса - это как обсуждать сферического коня в вакууме. В теории есть, на практике нет.
Зафиксировать решения в виде правил - предполагать, что лид должен принять решение и приказать их исполнять. Всё опять же сводится к тому, что лид хреновый, если этого не делает.
И тут можно даже занять сторону спецов, их обязанность в их узких рамках. Не они принимают решение. Они делают, как им говорят. Скажут предложить решение, значит предложат. Скажут обсудить проблему, и они просто поноют. Банально зачем им выполнять работу другого человека, который получает больше? И с другой стороны, ну ушел бы такой лид, что то поменялось бы? Да ничего.
Тут вопрос скорее не в масштабируемости, а в том, что неподходящий человек не на своем месте. Решаешь этот вопрос (считайтесь, баг, который мешает работать системе в целом), и другие сами отпадут, вот вам и масштабируемость заработает.
А как планировались спринты? Они ж как-то это делались.
Почему коммуникация разрушает ИТ