Вообще, ПМ — не «более высокая ступенька развития». ПМ — это человек, который берёт ответственность за проект, за команду и за нормальное отношение с заказчиком (если нет аккаунта). Поэтому его задача не только «попасть в треугольник проекта», но и сделать так, чтобы при этом все остались довольны. И, заметьте, в случае фэйла, крайним будет (и должен быть) руководитель проекта, а не команда.
Всё-таки на мой взгляд, в проекте главное — команда, и ПМы, которые считают свою работу бумажной, не до конца понимают смысл своей работы. Отличный пост есть у Джоэля Спольски — я ссылку уже кидал ниже.
Вся проблема в том, что мы пытаемся раздавать места. Этому — первое, тому — второе… Продукт и команда вещи настолько же независимые, насколько и связанные. У плохой команды не получится хороший продукт. У хорошей команды хороший продукт тоже не обязательно получится, но шансов больше. Есть хорошая статья Джоэля Спольски о менеджерах. Я ему верю и считаю очень крутым профессионалом.
Вопрос вполне понятен. Честно сказать — ожидал его гораздо раньше :). Очень надеюсь, что доля троллинга тут всё-таки есть, иначе, если вы всё это пишете на полном серьёзе, то мы вряд ли договоримся до чего-то конструктивного ;). Но я попробую всё-таки.
1) Саморегулирующихся систем действительно не бывает, ибо энтропия, как известно, в замкнутой системе не убывает. Другой вопрос в том, что в основу регулирования системы может быть положена либо личность (в плохом случае) либо процесс (в хорошем). Я как раз на эту тему написал постскриптум. Т.е. не команда сама по себе организуется (второй закон термодинамики нам это не позволит), а команда организуется с помощью процесса, который пришёл извне и поддерживается силами отдельных личностей (в идеале — всех её членов).
Скрам, как и любой другой аджайл или не-аджайл процесс этому способствует. Например, ежедневные стэндапы есть ни что иное, как регулирование системы.
В частности, скрам-мастер это именно тот, кто блокирует «наезды» со стороны бизнеса, который представляет product owner. Чтобы лучше понять, о чём моя статья, представьте, что product owner и скрам-мастер — одно и то же лицо.
Привожу пример, как вы и просили: Человек собирает 5 программистов и говорит: «сделайте вот эти фичи за два месяца». Как вы думаете, что будет через эти два месяца? Какова вероятность, что они «самосрегулируются» и продукт будет сделан?
2) Вопрос изначально некорректен. Я в ответ могу (конечно, не всерьёз, а для примера) задать вопрос: «как вы думаете, насколько начинает лениться и делать фигню команда при отсутствии руководителя и контроля, при этом прикрываясь непонятным для всех словом „скрам“, о котором не имеют ни малейшего понятия? ;)
А что будет, если все 100 программистов будут выяснять детали у заказчика напрямую?
Сразу разъясню, что задал эти два вопроса в шутку. Всё зависит от процессов и качеств самого ПМа. Если ПМ — дебил, то это не исправить. Впрочем, в случае, если это скрам-мастер или product owner, тоже.
Если ПМ грамотный и процесс соответствует, то практически никаких проблем нет. Тут могу поставить на кон свой опыт разработки, как программистом, так и ПМом. Почитайте статью, на которую я дал ссылку в самом начале поста.
3) Психологи говорят, что 7+-2. Не вижу поводов с ними не согласиться. Если команда больше, то нужно строить иерархию. Если меньше, то можно вести несколько.
Про то, что не бывает «саморегулирующейся системы», согласен на 146%.
А вот насчёт разных ПМов (если, конечно, имеется в виду именно руководитель проекта, который отвечает за бюджет, сроки и скоуп) не соглашусь. Функции одни и те же, на самом деле. Другое дело, если на ПМа «взвалить» ещё управление продуктами (а то и маркетинг) — вот тогда — да. Есть разница.
Когда команда 120 человек — появляются те самые ПМы, которые (в идеале) на светлой стороне, поэтому работа идёт именно с ними (а у них — карма такая, чтобы на них бизнес наезжал).
Хороший вопрос :). Ну там, конечно, месяц работы и тонны кода — исходниками одного метода не отделаешься.
Принцип такой — выставляются промежуточные значения через таймер и элементы, которые нужно перерисовать — перерисовываем, а те, которые не нужно — не перерисовываем (ваш Кэп :).
Есть easing-функция, по которой прогоняется значение по таймеру и duration. Мы получаем текущее значение и вызываем перерисовку. Собственно, оптимизация — грамотно выбрать только нужные объекты и перерисовывать только их.
Ну и, при стандартной анимации непонятно, как с одной на другую переключаться (если новая анимация началась, когда предыдущая ещё не закончилась). Здесь это решается легко и просто.
Почему-то кажется, что сделать продукт, для продвижения которого не надо бесплатных «заманух», не намного сложнее, чем сделать такую интересную бесплатную штуку, которая будет «сама себя продавать» (в нашем случае — раздавать).
Кстати, часто делят продукт на Standard / Premium… И пытаются монетизировать дополнительные услуги, типа внедрения, обучения, саппорта и т.д.
Всё-таки на мой взгляд, в проекте главное — команда, и ПМы, которые считают свою работу бумажной, не до конца понимают смысл своей работы. Отличный пост есть у Джоэля Спольски — я ссылку уже кидал ниже.
1) Саморегулирующихся систем действительно не бывает, ибо энтропия, как известно, в замкнутой системе не убывает. Другой вопрос в том, что в основу регулирования системы может быть положена либо личность (в плохом случае) либо процесс (в хорошем). Я как раз на эту тему написал постскриптум. Т.е. не команда сама по себе организуется (второй закон термодинамики нам это не позволит), а команда организуется с помощью процесса, который пришёл извне и поддерживается силами отдельных личностей (в идеале — всех её членов).
Скрам, как и любой другой аджайл или не-аджайл процесс этому способствует. Например, ежедневные стэндапы есть ни что иное, как регулирование системы.
В частности, скрам-мастер это именно тот, кто блокирует «наезды» со стороны бизнеса, который представляет product owner. Чтобы лучше понять, о чём моя статья, представьте, что product owner и скрам-мастер — одно и то же лицо.
Привожу пример, как вы и просили: Человек собирает 5 программистов и говорит: «сделайте вот эти фичи за два месяца». Как вы думаете, что будет через эти два месяца? Какова вероятность, что они «самосрегулируются» и продукт будет сделан?
2) Вопрос изначально некорректен. Я в ответ могу (конечно, не всерьёз, а для примера) задать вопрос: «как вы думаете, насколько начинает лениться и делать фигню команда при отсутствии руководителя и контроля, при этом прикрываясь непонятным для всех словом „скрам“, о котором не имеют ни малейшего понятия? ;)
А что будет, если все 100 программистов будут выяснять детали у заказчика напрямую?
Сразу разъясню, что задал эти два вопроса в шутку. Всё зависит от процессов и качеств самого ПМа. Если ПМ — дебил, то это не исправить. Впрочем, в случае, если это скрам-мастер или product owner, тоже.
Если ПМ грамотный и процесс соответствует, то практически никаких проблем нет. Тут могу поставить на кон свой опыт разработки, как программистом, так и ПМом. Почитайте статью, на которую я дал ссылку в самом начале поста.
3) Психологи говорят, что 7+-2. Не вижу поводов с ними не согласиться. Если команда больше, то нужно строить иерархию. Если меньше, то можно вести несколько.
Надеюсь, что ответил на ваши вопросы.
Про то, что не бывает «саморегулирующейся системы», согласен на 146%.
А вот насчёт разных ПМов (если, конечно, имеется в виду именно руководитель проекта, который отвечает за бюджет, сроки и скоуп) не соглашусь. Функции одни и те же, на самом деле. Другое дело, если на ПМа «взвалить» ещё управление продуктами (а то и маркетинг) — вот тогда — да. Есть разница.
Принцип такой — выставляются промежуточные значения через таймер и элементы, которые нужно перерисовать — перерисовываем, а те, которые не нужно — не перерисовываем (ваш Кэп :).
Есть easing-функция, по которой прогоняется значение по таймеру и duration. Мы получаем текущее значение и вызываем перерисовку. Собственно, оптимизация — грамотно выбрать только нужные объекты и перерисовывать только их.
Ну и, при стандартной анимации непонятно, как с одной на другую переключаться (если новая анимация началась, когда предыдущая ещё не закончилась). Здесь это решается легко и просто.
Если какой-то кусок кода интересует особо — скажите, подредактируем ;).
Кстати, часто делят продукт на Standard / Premium… И пытаются монетизировать дополнительные услуги, типа внедрения, обучения, саппорта и т.д.