Правильна статистика

Вся справа у відсотках :)

8 рис хорошого менеджера: Google

Сергій Брін та Ларрі Пейдж, засновники Google, на початку своєї кар"єри вважали, що в сфері ІТ менеджери є напотрібними. В 2002 році вони намагалися побудувати горизонтальну схему управління компанією. Вони вважали, що це сприятиме більш невимушеній атмосфері та полегшить виконання завдань, які перед ними тоді стояли.
Експеримент завершився за кілька місяців: співробітники зверталися до них далеко не з творчими проблемами. В подальшому стало зрозуміло, що менеджери корисні для широкого кола функцій: пояснення стратегії, значимість проектів, слідкують за кар"єрним ростом співробітників і за співвідношенням задач бізнесу та виконуваних процесів.

Зараз Google виділяє 8 рис хорошого менеджера:
1. Чуйний наставник.
2. Надає колективу свободу і не контролює кожен крок.
3. Стежить за успіхами підлеглих і намагається допомогти.

Скрам. Основи методології.

  Скрам це процесний підхід, що використовується для комплексного управління процесом.Скрам складається зі:
-  Скрам Команд (Scrum Teams), в яких розподілено відповідні ролі (roles)
- церемоній (events);
- артефактів (artifacts);
- правил (rules).
Скрам ґрунтується на теорії управління емпіричними процесами. В основі управління емпіричними процесами лежать три основні принципи:
- прозорість (transparency): важливі аспекти процесу повинні бути видимі для відповідальних за результат;
- перевірка (inspection): перевірка артефактів, та контрольпрогресу для своєчасного виявлення небажаних відхилень;
- адаптація (adaptation): при відхиленні від допустимих норм - необхідно вносити поправки або у процес, або у робочі матеріали.

Скрам прописує 4 формальні можливості для перевірки та адаптації:- Планування Спринту (Sprint Planning Meeting);- Щоденний Скрам (Daily Scrum);- Огляд Спринту (Sprint Review Meeting);- Ретроспектива Спринту (Sprint Retrospective);

10 смертних гріхів в оцінці складності та термінів розробки ПО

1 . Підмінювати поняття: "проектні цілі" та "проектні оцінки".
Ситуація: запит від керівництва на оцінку трудомісткості проекту, який планується показати на щорічній виставці за кордоном.
Проблема: оцінка трудомісткості (скільки часу займе розробка) поєднується з цілями проекту ("показати на виставці у визначений час").
Рішення: ітеративне вирівнювання цілей та оцінок. Наприклад: урізання функціоналу для запобігання зривам термінів здачі проекту.

2 . Говорити «Так» тоді , коли ви , насправді , розумієте «Ні».
Ситуація: за столом переговорів інтравертивні розробники та екстравертивні, досвідчені "продажники".
Питання: через який час розробники погодяться на всі "вкидання" "продажників"?

3. Давати обіцянки на ранній стадії Конуса невизначеності.

Горизонтальна вісь: час
Вертикальна вісь: значення помилки , яка закладається при оцінці трудомісткості

Проблема: не можна давати обіцянки в той момент часу (крайня ліва частина конуса) , коли величина помилки ще занадто велика. За МакКоннелом межа впевненості десь в районі 1,5 x , тобто той момент часу , коли ймовірна помилка становитиме 1,5 рази як у більшу , так і в меншу сторону. Давати обіцянки раніше цього моменту - свідомо піддавати себе занадто великому ризику.