Поток задач. Менеджерская домашка

[ksoftware]

Во всех, компаниях, которые я видел изнутри и у которых был продукт, я наблюдал одну и ту же проблему - жопа с потоком задач. Все такие команды встречались регулярно, обычно раз в неделю, составляли список задач, и работали над ним неделю.

И всё в целом было ок, если бы к очередному понедельнику не оказывалось, что, чёрт побери, половина задач не

Comments

[ext_4009502]

Из списка следует, что какое-то говно по каждой несделанной задаче - это исполнители мудаки. А менеджер такой типа молодец, надавал задачек и ждёт чуда 😂

[nfrjtdjnbvz]

Решение будет звучать не очень элегантно, но увы, я утратил веру в серебряные пули и предпочитаю многокритериальную оптимизацию. Поэтому ответ из трёх частей, где каждая важна.

1. Сильные люди. Это значит регулярно на постоянной основе: а) искать и находить сильных, вовремя удалять из команды слабачков, б) учиться, всем учиться, и учиться сразу всему, включая управление.

2. Интересные задачи. Это значит внимательно оценивать то, что мы собираемся делать не только со стороны «полезно ли это проекту, бизнесу, потребителю», но и со стороны «торкает ли это команду». Если команду торкают только фантики, значит это недостаточно сильные люди. Сильных людей будет торкать важные вещи, но не любые; надо учитывать этот фактор. Чем больше торкает, тем меньше сил требуется на управление.

3. Система красных лампочек. Это значит, что как только где-то что-то идёт не по плану, это моментально должно быть заметно. Акцент не на исправление ситуации, не на избегание проблем, а на своевременное осознание проблемы и информирование о проблеме. Для этого

[dunaich]

Мы использовали методологию скрама следующим образом

[eugene_ivanov]

смешно как-то

зачем что-то оценивать то?

есть задача - её берут и делают.

ну вот например, есть строители, им нужно покрыть крышу.
они берут и строят.
зачем им оценивать то это?
конечно, они могут оценить грубо время, но смысл?
всё равно крышу то крыть нужно.

также и в создании продукта в программировании
если что-то нужно сделать, люди берут и делают, день за днём программируют и однажды это у них получается =)

а вы только и тратите время на оценки сроков =)
смешные

[ext_4883070]

Хорошо, когда области интересов у участников команды пересекаются.
Либо в одном уровне, либо иерархично. Ещё лучше - многомерно.
Чтоб сама система быстро показывала моменты срыва.
А в идеале - сама и перенастраивалась.

В самом тупом виде, пример из авионики: два идентичных модуля ставят для решения одной задачи.
Для коллектива это означает два сотрудника на одну задачу. В надежде, что они будут друг друга контролировать.

Можно выстраивать конвейер. Тогда каждый последующий будет ждать/требовать от предыдущего.
Но, не все процессы однородны и монотонны. В этом проблема.

В иерархии - выделяется специальный чувак (менеджер), который выстраивает процессы, ищет слабые звенья и думает, как оптимизировать систему. Это очень хорошая роль, если менеджер не мудак. Надо иметь определённым образом заточенный мозг, который уважает членов команды, любит задачу(проект) и обладает набором инструментов для работы.

P.S. А вообще, идеала нет. И быть не может. Как и кнопки «сделать всё». Надо любить работать.

[ksoftware]

Моё решение - кнопка «Не сделать» и ещё несколько инструментов:
https://ksoftware.livejournal.com/412761.html