Pull to refresh

Comments 9

Да по закону Амдала максимум можно вдвое уведичить скорость разработки, в 3-4 раза - это уже из области фантастики))

  1. Определите ясные роли и обязанности каждого участника группы. Чтобы каждый понимал, какую работу он выполняет и как это влияет на общую цель.

Ничего личного, никого не хочу обидеть. Для меня лучше ставить конкретные задачи по Разработке, чем мне объяснять за чьей ролью я буду подчищать ради общей цели ))

  1. Свяжите цели проекта с индивидуальными интересами участников. Если результат работы будет непосредственно влиять на личные достижения, то мотивация работать на полную мощность повысится.

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

  1. Обеспечьте эффективную коммуникацию и получение обратной связи. Чтобы можно было показывать свой вклад команде, а также знать, что их работа оценивается и ценится.

Смесь KPI c доской показателей. Опять перегруз. Важнее видеть при коллективной разработке, кто что написал, но в реальном времени можно оценить только оконченные задачи и видеть сколько кому на задачу выдано. Но пока задача не закончена нет никакой гарантии, что все будет в графике. Это разработка фарс-мажор это реальность, не всегда пишется легко, бывают затыки. Тут лучшая мотивация - совет.

  1. Декомпозируйте задачи и отслеживайте их выполнение. Чтобы любой участник мог видеть и показать свой личный вклад в проект.

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

ПС

Чем проще система, тем она жизнеспособнее.

  1. Конкретные задачи сложнее, чем обрисовать вектор, если это задача по работоспособности, например, а не просто новый раздел забацать.

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

Расчет количества связей

....

Участники команды разработки постоянно общаются между собой: обсуждают рабочие моменты, делятся предложениями, отчитываются о проделанной работе и т.д. Между ними возникают связи, число которых увеличивается с ростом людей в команде.

Вот поэтому всё крупное в конце-концов вырождается в империю (иерархию) - количество связей равно числу участников (минус один ;))))

Ну да, так и знал, что сам себе команда.

Сарказм: итак, выяснили, что 9 женщин не могут ... потому что команды в 9 и более являются самыми дорогими.

Что по поводу 3-4 женщин? Наверняка месяцев за 5 (плюс/минус) справятся.

Если без сарказма, то самое полезное слово:

Декомпозируйте

Остальное может совсем не получиться. Декомпозиция тоже может не получиться, но всё равно её делайте.

Прим.: по мне, продуктивность очень сильно возрастает, когда человек занимается тем, что хорошо (отлично) умеет делать. И продуктивность возрастает намного сильнее, чем увеличение количества человек в команде.

Да, сейчас я Капитан Очевидность. Только все ли здесь занимались только тем, что хорошо умеют делать? Вот прямо совсем ничего другого?

9 женщин никак не могут уменьшить latency, но throughput вполне, в 9 раз. И через 9 месяцев вполне начнут рождать каждый месяц по ребенку.

Может 9 женщин не смогут родить ребенка за 1 месяц, но искусственный интеллект может их изобразить ?

Sign up to leave a comment.

Articles