IMHO, очень часто словом Agile в проектном управлении пытаются мягко заменить словосочетание "здравый смысл", а словом Waterflow - мягко заменить словосочетание "даже ежу понятно, что так никто не работает". Но вот что интересно, после того как здравый смысл начинают называть Agile, здравый смысл на проекте начинает все больше становится похожим на Agile. В том числе и тогда, когда это противоречит здравому смыслу.
А чего Вам не хватает в системах управления проектами? Какие возможности Вы хотели бы к ним добавить?
Спасибо за статью. Для решения проблем управления на проектах, несколько лет назад я предложил подход в основу которого были положены принципы управления проектами с высокой степенью неопределенности (управление научно-исследовательской работой / управление войсками при ведении боевых действий). Более подробно об основных принципах и результатах применения этого подхода вы можете посмотреть здесь. Для тех кто не любит читать, мы даже запилили небольшой видос. Было бы весьма интересна Ваша критика данного подхода.
Настоящий Agile требует высокой квалификации участников. Если ваша команда состоит из джунов, выстроить Agile почти невозможно. Почему?
Если присмотреться, методика организации работ в одном из самых фактически скопирована из тактики применения диверсионно-разведывательных групп. И это неудивительно, для тех кто хоть немного знаком с биографией Джефа Сазерленда, автора одной из самых известных книг про Scrum. В учебнике Atlassian Agile Coach упоминается о Таннере Уортэме, тренере Agile и старшем техническом менеджере в Likedin, который провел 10 лет в морской пехоте США. По его мнению, он начал практиковать Agile еще до того, как узнал, что для него есть название. Для него это называлось «Leading Marine». А теперь представьте, что группу спецназа набрали из джунов. Что получится?
Да, мне часто рекомендуют делить мои лонгриды на кусочки. Однако, на мой взгляд, тогда теряется системность и связность между взаимозависимыми элементами. По большому счету мне хотелось рассмотреть проблемы управления именно с точки зрения увеличения предсказуемости проекта и, как следствие, уменьшение страхов отравляющих жизнь. На мой взгляд, средства от этой напасти нужно рассматривать в комплексе. Если поднятые проблемы рассматривать по отдельности, то они многим топам кажутся мелкими, не заслуживающими внимание...
Со многим согласен, особенно в части пубертатного возраста IT-индустрии. Но не со всем. Не нужно думать год над правильной архитектурой. За год, без апробации и обратной связи, любая архитектура безнадежно протухнет. РП надо думать о своевременной перестройке структуры команды в зависимости от уровня зрелости проекта. И делать соответствующие превентивные телодвижения. Я тоже обычно никогда не встречался с полным пасьянсом когда приходил на проект. С накоплением опыта я понял, что первейшая обязанность РП - это как раз собирать этот пасьянс. Вы говорите у вас есть бюджет на 9 сотрудников? Сначала договоритесь с топами на право РП перераспределять этот бюджет. Без широкой рекламы. Обоснование своей позиции рекомендую строить на языке цифр (деньги/время). По-взрослому. С учетом периодов финансирования. И с учетом рынка. Зарплатный калькулятор Хабр-карьеры и статистика ЦБ по инфляции Вам в помощь.. Когда проект стартует иногда достаточно и двух-трех человек. И ведущий разработчик может совмещать функции РП. Беда в том, что по мере раста команды такой РП не перестает быть разработчиком. Но когда в команде уже 9 сотрудников, это явный признак того, что РП должен заниматься только руководством (разработка и внедрение правил и регламентов, организация взаимодействия, обучения, контроль обобщенных показателей и т.п. ) и не пытаться заменить собой сотрудников. У вас не хватает денег на архитектора? Пригласите его на четверть ставки. Я видел мало людей которые отказываются от лишних денег. Иногда, на моих проектах работают топовые разработчики на зарплате джуна. Как раз для точечного решения архитектурных проблем. Обратите внимание на роли аналитиков. Если в команде 9 сотрудников, то аналитиков должно быть не менее трех-четырех. И лучше если они будут выращены прямо в команде (я уже про это как то писал). Постепенно, я сформировал в головах заказчиков и топов такое отношение, что эффективное кодирование может быть после согласования соответствующих технических решений (не ТЗ). И уточнения сроков реализации ПОСЛЕ согласования этих самых решений. Вам не дают денег на нормальных разработчиков? Может стоить из пяти джунов на конкурсной основе оставить двух-трех, а на освободившиеся деньги поднять зарплату достойным сотрудникам? Кстати, как из пяти сотрудников сделать трех, не уменьшая общий бюджет и не потеряв, но укрепив, доверие команды - это более сложная задача, чем как из трех сделать пять. Задача для РП. Все эти рекомендации конечно не "серебряная пуля" и не панацея. Но, все же... Спасение утопающих остается делом рук самих утопающих.
При наличии цитирования можно "провалиться" на список статей кликнув на дату публикации (в первой колонке). Список ссылающихся статей выведется в нижней части формы после основной таблицы. Поскольку мы не ставили целей регулярного пересканирования статей, карма показывается не совсем точно, поскольку за время прошедшее со времени сканирования статей она могла подрасти.
Полагаю, что этот баннер характеризует условия франшизы. Собственно там все обучение идет по переведенным импортным материалам. Наставники отсутствуют. Есть только администраторы регулирующие организационные вопросы. Студенты обучают сами себя. Выдаются задания, назначаются сроки, ответы фиксируются в системе. Выживают те, кто смог подстроится к этой системе. Сильнейшие получают офферы от организатора (Сбера) и от подписавшихся работодателей (например, Yandex).
"На фига в колхозе бесы, Если бес не продуктивен, Ни по шерсти, ни по мясу, Ни тем более по яйцам... " Веня Д'ркин Я так понял, что речь в статье идет о выпускнике американского колледжа. Я расскажу о подмосковных. Четвертый год пытаюсь сотрудничать. Три раза приглашали быть председателем выпускной комиссии по специальности 09.02.07 «ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ПРОГРАММИРОВАНИЕ». Наверно больше не пойду - стремно ставить свою подпись в дипломах за такие знания. 90% выпускников не знают что такое SQL (в т.ч. и те, кому выдают красные дипломы). Через экзамены прошли ~ 75 выпускников. На первом году сотрудничества взял в штат 1(одного) выпускника (в рамках дипломной работы представил реализованный на фрилансе заказ - устройство на arduino для поливки комнатных растений с управлением через Интернет). Проводил несколько собраний со студентами - звал к себе на стажировку. Завел специальный для этого проект (полагаю тематика ностальгична). Помнится на одно из таких собраний пришло человек 100. Я даже поначалу испугался. Что мне с ними со всеми делать если все придут на мою стажировку? Из 100 на призыв откликнулось 7. Из них до выдачи хоть каких то результатов "дожило" 0 (ноль) студентов. Пытался привлечь к своему учебному проекту студентов из МИИТ (у одного сотрудника сын учится на втором курсе). Этим студентам поставили учебную задачу - создать стартап. Ну я и предложил через своего знакомого свой проект для группы заинтересованных студентов. Студенты были согласны, но комиссия на кафедре проект отклонила. Стартап должен быть рентабельным. В общем на этом сотрудничество и закончилось. Про прохождение и результаты одной из стажировок студента-"программиста" я уже писал раньше. Если буду брать студентов на вакансии программистов, то только после успешного прохождения неоплачиваемой полугодовой стажировки. Было б совсем тоскливо, вместе с тем... Потенциально есть очень много людей которые хотят попасть в IT, но не знают как. Этой зимой приобщился к интенсиву школы 21 (франшиза школы 42). Универ однозначно не заменит, однако ... Первый раз одновременно видел в одном месте так много людей страстно желающих программировать (набор на 26 дневный интенсив около 600 человек). И у нах получалось. Базовая подготовка кандидатов - "с нуля". GIT и код - с первого дня. Кстати, ограничений по возрасту в этой школе в настоящее время нет. Думал встретить там в основном молодежь, но по моим наблюдениям средний возраст абитуриентов 30-35. Понял, что еще "не вмерла" IT в РФ... Надежда умирает последней...
Спасибо за перевод. Очень крутая статья. Однако, в первом предложении выводов фраза:
еще несколько секунд каждый день, чтобы сделать запись, когда вы начали работать над конкретной задачей.
на мой взгляд переведена не совсем верно. На мой взгляд, это очень важная фраза и должна быть интерпретирована так:
< ... еще несколько секунд каждый день, для учета рабочего времени (трудозатрат), которое было потрачено на выполнение конкретной задачи>.
В Вашем варианте перевода создается впечатление, что надо фиксировать время начала работы над задачей. А по факту, от сотрудника требуется ежедневная обратная связь о трудозатратах по конкретным задачам над которыми он работал. Добавлю от себя, что еще, в случае необходимости (если разработчик видит, что не укладывается в план), требуется переоценка времени необходимого для завершения конкретной задачи. На основании этой переоценки, РП может заблаговременно скорректировать сроки (без оказания давления на исполнителей).
Спасибо за развернутый ответ. Однако хотел отметить, что в моих статьях описаны типовые процессы не для Ланита (в который кстати входит более 30 компаний), а только для моей проектной команды. Несмотря на то, что я публикуюсь в блоге Ланита, мои подходы не являются общепринятыми и больше демонстрируют толерантность редколлегии к моему личному мнению, чем корпоративные стандарты. Что касается масштабов проекта для которых необходимо оформление технических решений, то со временем, не сразу, для себя я понял, что разработка и согласование технических решений необходимо абсолютно для всех заданий на разработку ПО. Раньше я думал что примерно 80% требований заказчика не требуют уточнения. После сбора статистики в течении 8 лет я точно знаю что 100% требований заказчика требует уточнения. Именно превентивное согласование технических решений на связанные группы требований (не путать с техническим заданием) дает хоть какие то гарантии успешного завершения проекта.
В приведенном процессе фактически отсутствует этап проектирования и согласования технического решения. Детализации и уточнения требований заказчика по моему опыту недостаточно. Пример регламента технического решения можно посмотреть здесь.
Я бы разделил п.4 на 2: менять регламенты и менять их к лучшему - это два разных уровня. В одной компании поменяли регламенты сопровождения, после чего продолжительность обслуживания инцидентов возросла в 6-8 раз...
Дополнительная пища: как декомпозировать задачи, у исходно туманны трудозатраты (например, исследование возможности применения новой технологии); какие именно плагины JIRA применялись для построения дашбордов; как ведется учет трудозатрат на декомпозицию и планирование, какова доля этих трудозатрат от бюджета рабочего времени проектной группы, кто именно проводит декомпозицию; каким образом связываются между собой декомпозированные задачи (как понять что это кусочки слона, а не оленя и как узнать текущую степень реализации слона); как, какие и в каких единицах измеряются потери на проекте....
IMHO, статья была бы на порядок полезнее, если бы Вы объяснили какие именно атрибуты задач JIRA использованы для построения и назначение каждого из этих красивых графиков, гистограмм, и бубликов. И что обозначают засекреченные полутона? И в особенности хотелось бы узнать, какие именно телодвижения надо делать руководителю исходя из этих картинок...
IMHO, очень часто словом Agile в проектном управлении пытаются мягко заменить словосочетание "здравый смысл", а словом Waterflow - мягко заменить словосочетание "даже ежу понятно, что так никто не работает". Но вот что интересно, после того как здравый смысл начинают называть Agile, здравый смысл на проекте начинает все больше становится похожим на Agile. В том числе и тогда, когда это противоречит здравому смыслу.
Спасибо за статью. Для решения проблем управления на проектах, несколько лет назад я предложил подход в основу которого были положены принципы управления проектами с высокой степенью неопределенности (управление научно-исследовательской работой / управление войсками при ведении боевых действий). Более подробно об основных принципах и результатах применения этого подхода вы можете посмотреть здесь. Для тех кто не любит читать, мы даже запилили небольшой видос. Было бы весьма интересна Ваша критика данного подхода.
Если присмотреться, методика организации работ в одном из самых фактически скопирована из тактики применения диверсионно-разведывательных групп. И это неудивительно, для тех кто хоть немного знаком с биографией Джефа Сазерленда, автора одной из самых известных книг про Scrum. В учебнике Atlassian Agile Coach упоминается о Таннере Уортэме, тренере Agile и старшем техническом менеджере в Likedin, который провел 10 лет в морской пехоте США. По его мнению, он начал практиковать Agile еще до того, как узнал, что для него есть название. Для него это называлось «Leading Marine».
А теперь представьте, что группу спецназа набрали из джунов. Что получится?
Да, мне часто рекомендуют делить мои лонгриды на кусочки. Однако, на мой взгляд, тогда теряется системность и связность между взаимозависимыми элементами. По большому счету мне хотелось рассмотреть проблемы управления именно с точки зрения увеличения предсказуемости проекта и, как следствие, уменьшение страхов отравляющих жизнь. На мой взгляд, средства от этой напасти нужно рассматривать в комплексе. Если поднятые проблемы рассматривать по отдельности, то они многим топам кажутся мелкими, не заслуживающими внимание...
Со многим согласен, особенно в части пубертатного возраста IT-индустрии. Но не со всем.
Не нужно думать год над правильной архитектурой. За год, без апробации и обратной связи, любая архитектура безнадежно протухнет. РП надо думать о своевременной перестройке структуры команды в зависимости от уровня зрелости проекта. И делать соответствующие превентивные телодвижения.
Я тоже обычно никогда не встречался с полным пасьянсом когда приходил на проект. С накоплением опыта я понял, что первейшая обязанность РП - это как раз собирать этот пасьянс. Вы говорите у вас есть бюджет на 9 сотрудников? Сначала договоритесь с топами на право РП перераспределять этот бюджет. Без широкой рекламы. Обоснование своей позиции рекомендую строить на языке цифр (деньги/время). По-взрослому. С учетом периодов финансирования. И с учетом рынка. Зарплатный калькулятор Хабр-карьеры и статистика ЦБ по инфляции Вам в помощь..
Когда проект стартует иногда достаточно и двух-трех человек. И ведущий разработчик может совмещать функции РП. Беда в том, что по мере раста команды такой РП не перестает быть разработчиком. Но когда в команде уже 9 сотрудников, это явный признак того, что РП должен заниматься только руководством (разработка и внедрение правил и регламентов, организация взаимодействия, обучения, контроль обобщенных показателей и т.п. ) и не пытаться заменить собой сотрудников. У вас не хватает денег на архитектора? Пригласите его на четверть ставки. Я видел мало людей которые отказываются от лишних денег. Иногда, на моих проектах работают топовые разработчики на зарплате джуна. Как раз для точечного решения архитектурных проблем. Обратите внимание на роли аналитиков. Если в команде 9 сотрудников, то аналитиков должно быть не менее трех-четырех. И лучше если они будут выращены прямо в команде (я уже про это как то писал). Постепенно, я сформировал в головах заказчиков и топов такое отношение, что эффективное кодирование может быть после согласования соответствующих технических решений (не ТЗ). И уточнения сроков реализации ПОСЛЕ согласования этих самых решений. Вам не дают денег на нормальных разработчиков? Может стоить из пяти джунов на конкурсной основе оставить двух-трех, а на освободившиеся деньги поднять зарплату достойным сотрудникам? Кстати, как из пяти сотрудников сделать трех, не уменьшая общий бюджет и не потеряв, но укрепив, доверие команды - это более сложная задача, чем как из трех сделать пять. Задача для РП.
Все эти рекомендации конечно не "серебряная пуля" и не панацея. Но, все же...
Спасение утопающих остается делом рук самих утопающих.
Этот вопрос полезно задавать на собеседованиях работодателю: "Чего вы от меня ждете через 1-3-5 лет?" Ответ порой многое объясняет.
Идея классная. Мы об этом не подумали. Надеюсь, что Хабр реализует такое в штатных механизмах поиска.
Под индексом цитирования здесь понимается количество других авторов Хабра, ссылающихся на эту статью. Именно авторов, а не ссылающихся статей.
При наличии цитирования можно "провалиться" на список статей кликнув на дату публикации (в первой колонке). Список ссылающихся статей выведется в нижней части формы после основной таблицы. Поскольку мы не ставили целей регулярного пересканирования статей, карма показывается не совсем точно, поскольку за время прошедшее со времени сканирования статей она могла подрасти.
Добавлю от себя: желание учится новому и умение признавать свои ошибки.
По своему опыту, отмечу причину выгорания в этом конкретном случае:
Лекарство: если есть по штату зам - ничего не делай сам.
Полагаю, что этот баннер характеризует условия франшизы. Собственно там все обучение идет по переведенным импортным материалам. Наставники отсутствуют. Есть только администраторы регулирующие организационные вопросы. Студенты обучают сами себя. Выдаются задания, назначаются сроки, ответы фиксируются в системе. Выживают те, кто смог подстроится к этой системе. Сильнейшие получают офферы от организатора (Сбера) и от подписавшихся работодателей (например, Yandex).
"На фига в колхозе бесы,
Если бес не продуктивен,
Ни по шерсти, ни по мясу,
Ни тем более по яйцам... "
Веня Д'ркин
Я так понял, что речь в статье идет о выпускнике американского колледжа. Я расскажу о подмосковных. Четвертый год пытаюсь сотрудничать. Три раза приглашали быть председателем выпускной комиссии по специальности 09.02.07 «ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ПРОГРАММИРОВАНИЕ». Наверно больше не пойду - стремно ставить свою подпись в дипломах за такие знания. 90% выпускников не знают что такое SQL (в т.ч. и те, кому выдают красные дипломы). Через экзамены прошли ~ 75 выпускников. На первом году сотрудничества взял в штат 1(одного) выпускника (в рамках дипломной работы представил реализованный на фрилансе заказ - устройство на arduino для поливки комнатных растений с управлением через Интернет). Проводил несколько собраний со студентами - звал к себе на стажировку. Завел специальный для этого проект (полагаю тематика ностальгична). Помнится на одно из таких собраний пришло человек 100. Я даже поначалу испугался. Что мне с ними со всеми делать если все придут на мою стажировку? Из 100 на призыв откликнулось 7. Из них до выдачи хоть каких то результатов "дожило" 0 (ноль) студентов. Пытался привлечь к своему учебному проекту студентов из МИИТ (у одного сотрудника сын учится на втором курсе). Этим студентам поставили учебную задачу - создать стартап. Ну я и предложил через своего знакомого свой проект для группы заинтересованных студентов. Студенты были согласны, но комиссия на кафедре проект отклонила. Стартап должен быть рентабельным. В общем на этом сотрудничество и закончилось.
Про прохождение и результаты одной из стажировок студента-"программиста" я уже писал раньше. Если буду брать студентов на вакансии программистов, то только после успешного прохождения неоплачиваемой полугодовой стажировки.
Было б совсем тоскливо, вместе с тем... Потенциально есть очень много людей которые хотят попасть в IT, но не знают как. Этой зимой приобщился к интенсиву школы 21 (франшиза школы 42). Универ однозначно не заменит, однако ... Первый раз одновременно видел в одном месте так много людей страстно желающих программировать (набор на 26 дневный интенсив около 600 человек). И у нах получалось. Базовая подготовка кандидатов - "с нуля". GIT и код - с первого дня. Кстати, ограничений по возрасту в этой школе в настоящее время нет. Думал встретить там в основном молодежь, но по моим наблюдениям средний возраст абитуриентов 30-35. Понял, что еще "не вмерла" IT в РФ... Надежда умирает последней...
Спасибо за перевод. Очень крутая статья. Однако, в первом предложении выводов фраза:
на мой взгляд переведена не совсем верно. На мой взгляд, это очень важная фраза и должна быть интерпретирована так:
< ... еще несколько секунд каждый день, для учета рабочего времени (трудозатрат), которое было потрачено на выполнение конкретной задачи>.
В Вашем варианте перевода создается впечатление, что надо фиксировать время начала работы над задачей. А по факту, от сотрудника требуется ежедневная обратная связь о трудозатратах по конкретным задачам над которыми он работал. Добавлю от себя, что еще, в случае необходимости (если разработчик видит, что не укладывается в план), требуется переоценка времени необходимого для завершения конкретной задачи. На основании этой переоценки, РП может заблаговременно скорректировать сроки (без оказания давления на исполнителей).
Спасибо за развернутый ответ. Однако хотел отметить, что в моих статьях описаны типовые процессы не для Ланита (в который кстати входит более 30 компаний), а только для моей проектной команды. Несмотря на то, что я публикуюсь в блоге Ланита, мои подходы не являются общепринятыми и больше демонстрируют толерантность редколлегии к моему личному мнению, чем корпоративные стандарты. Что касается масштабов проекта для которых необходимо оформление технических решений, то со временем, не сразу, для себя я понял, что разработка и согласование технических решений необходимо абсолютно для всех заданий на разработку ПО. Раньше я думал что примерно 80% требований заказчика не требуют уточнения. После сбора статистики в течении 8 лет я точно знаю что 100% требований заказчика требует уточнения. Именно превентивное согласование технических решений на связанные группы требований (не путать с техническим заданием) дает хоть какие то гарантии успешного завершения проекта.
В приведенном процессе фактически отсутствует этап проектирования и согласования технического решения. Детализации и уточнения требований заказчика по моему опыту недостаточно. Пример регламента технического решения можно посмотреть здесь.
Я бы разделил п.4 на 2: менять регламенты и менять их к лучшему - это два разных уровня. В одной компании поменяли регламенты сопровождения, после чего продолжительность обслуживания инцидентов возросла в 6-8 раз...
Дополнительная пища: как декомпозировать задачи, у исходно туманны трудозатраты (например, исследование возможности применения новой технологии); какие именно плагины JIRA применялись для построения дашбордов; как ведется учет трудозатрат на декомпозицию и планирование, какова доля этих трудозатрат от бюджета рабочего времени проектной группы, кто именно проводит декомпозицию; каким образом связываются между собой декомпозированные задачи (как понять что это кусочки слона, а не оленя и как узнать текущую степень реализации слона); как, какие и в каких единицах измеряются потери на проекте....
IMHO, статья была бы на порядок полезнее, если бы Вы объяснили какие именно атрибуты задач JIRA использованы для построения и назначение каждого из этих красивых графиков, гистограмм, и бубликов. И что обозначают засекреченные полутона? И в особенности хотелось бы узнать, какие именно телодвижения надо делать руководителю исходя из этих картинок...
Спасибо, поправлю! Что скажешь... Сеанс кодотерапии выровнял кривые руки РП, исковерканные менеджментом, не до конца... ;)