Следующим шагом нам вводят почасовые отчеты. Я подсчитываю экономическую эффективность данного решения, сколько команда будет тратить на заполнение таких отчетов
Не совсем понял этот тезис. Т.е. до этого команда состоявшая из сотрудников работавших на удаленке на удаленке не вела таймтрекинг? Или речь о чем то другом? И сколько времени по Вашей оценке необходимо сотруднику для составления таких отчетов? И с помощью какого инструмента (Word/Excel/Jira/....)?
На мой взгляд в статье Вы прекрасно описали последствия, в случае если результаты таймтрекинга приравниваются руководством к результатам работ. Весьма распространенное заблуждение. Однако, в своей деятельности я тоже пришел к необходимости таймтрекинга. Однако, в нашем случае таймтрекинг используется только для того, чтобы превентивно выявить риски и адекватно спланировать работу сотрудников так, чтобы не было переработок и срыва сроков. Как я пришел к такой жизни и как у нас в команде используются результаты таймтрекинга я подробно описал здесь и здесь. Буду рад конструктивной критике.
Можно почитать здесь и здесь. Надо отметить что в настоящее время правила в Школе 21 не такие жесткие как описаны в статьях. Например, пробовать поступать можно без ограничения возраста и количества раз.
Да, я в курсе, что Школа 21 франшиза Ecole 42. По слухам сейчас эту франшизу целиком перекупили американцы. Моя рекомендация основывается на личном опыте прохождения интенсива (бассейна) в Школе 21, более чем 20 летнего опыта в IT индустрии и более чем 10 летнего опыта преподавания в вузах. Поначалу, поступив на интенсив я хотел посмотреть изнутри на эту разрекламированную школу. Ну и хотел на уровне современных требований реанимировать свои навыки программирования, изрядно изуродованные работой на руководящих должностях. Я думал что со своим-то опытом, я легко пройду этот интенсив без отрыва от основной работы. Не тут то было. Уже в конце первой недели, я пришел к своему руководителю, рассказал о своем обучении и попросил чтобы меня "не кантовали" еще три недели. Это оказался действительно очень интересный челендж. Да, действительно, ограничения по кодингу были, но как правило не жесткие, скорее рекомендации, если только того не требовало конкретное задание. Не забывайте, что это учебные задачи, на которых цель - обучить находить решения в нетривиальных условиях. Институт Школа 21 не заменит. Однако, тем не менее, отличная практика для людей которые хотят связать свою жизнь с программированием. Что интересно, на интенсиве который я проходил, втихую обучались несколько топ-менеджеров Сбера. Не относящиеся по своему основному роду деятельности к IT. Не с целями поступить в Школу, а только пройти этот интенсив. "Проплыть бассейн" - как говорили в Школе. И они старались изо всех сил. На равных с молодыми студентами. И на мой взгляд, действительно демонстрировали, что на свои должности были назначены прежде всего за интеллект. На мой взгляд - супер практика со стороны руководства Сбера, направленная на повышение степени понимания топами внутренних механизмов IT.
Он не может себя заставить вести машину в бой сквозь туман.
Это не туман. Это дым от горящего нашего танка, за которым до того как этот танк подбили и ехала самоходка. Рекомендую первоисточник - книгу Виктора Курочкина, который знал о чем писал не по наслышке. Книга еще более реальна. И может на заставку стоит поставить кадр из фильма, а не игрушку-самурая? Кстати, как пособие по действительно эффективному менеджменту в экстремальных условиях рекомендую посмотреть незаслуженно забытую дилогию "Красная площадь" и фильмы об адмирале Ф.Ф.Ушакове.
IMHO - Одну из причин выгорания очень здорово описал Андрей Тысленко:
«Мы проводили эксперимент. Не один десяток раз. Не одну сотню раз. Мы берем и опрашиваем директора. Дайте перечень задач, которые Вы поставили за последний месяц. Из них укажите те, которые Вы считаете выполненными. Потом мы берем всех людей, которые сидят под директором, и задаем им очень простой вопрос: напишите все задачи, которые вы получили от директора и которые вы считаете, что выполнили. Получается забавная вещь. В случае, даже когда уже есть информационный контроль, но не выделен человек, который последовательно и шаг за шагом а) фиксирует и б) отслеживает выполнение, то самый большой процент пересечения этих задач составляет 6% (шесть процентов)».
tldr ?Сорри... Это не я .... Это Джефф Сазерленд... Однако, я бы не был столь категоричен в отношении Agile. По моему убеждению Scrum копирует тактику диверсионно-разведывательных групп. И это неудивительно для тех кто хоть немного знаком с биографией Джеффа Сазерленда. Для выполнения задач спецназа в эти группы подбираются суперпрофессионалы. Они не заморачиваются с оформлением документации. Горизонт планирования не превышает нескольких дней. Они заточены на получение конкретного результата. Как говорится "Никто, кроме нас!". И некоторые "гении" полагают, что эти, без иронии, суперпрофессионалы могут решить любые задачи... Если бы было бы так... Однако, иногда наблюдая как фанатично некоторые мои коллеги-менеджеры пытаются внедрить в руководство проектами то, что они называют «scrum» и «agile», я задаюсь вопросом - а всегда ли оправдано применение спецназа?
Истории об одних из лучших спецназовцев средневековья - ниндзя (или синоби) - ушли в область преданий, после того как регулярные войска, по приказу Оды Нобунаги, взяли под свой контроль провинцию Ига. Прототип Евгения Таманцева из легендарной книги В. Богомолова «Момент истины» погиб зимой 1945 года в окопном бою при неожиданном прорыве танковой группы немцев. Хироо Онода, младший лейтенант войсковой разведки Вооружённых сил Японии, успешно вел диверсионную деятельность на филиппинском острове Лубанг в течении 32 лет! Но разве Япония вошла в число победителей во Второй мировой войне? Первый вывод: стратегические задачи решаются не спецназом, а регулярными войсками. Второй вывод: как только спецназ теряет свое главное преимущество - маневр - он превращается в простую пехоту. И в этом случае нужны уже другие способы организации проектов.
Но ни один вменяемый военачальник не будет привлекать элиту для решения боевых задач, которые могут выполнить обычные подразделения. Высокий риск очень скоро безвозвратно лишиться всей этой элиты, при таком подходе, как правило, удерживает командование от таких необдуманных решений.
Вы можете мне возразить, что на программном проекте тоже могут быть безвозвратные потери. И я с вами соглашусь. Однако ответственность руководителя за безвозвратные потери на программном проекте и при ведении боевых действий несоизмерима. Поэтому непуганые менеджеры программных проектов, ошалев от невиданных перспектив увеличения производительности, о которых написано в книжках про Scrum, пытаются применять этот поход везде и всюду. А потом еще делятся на IT-конференциях и на Habr своим успешным проектным опытом о том, как можно эффективно забивать гвозди с помощью микроскопа...
Джефф Сазерленд в своей знаменитой книге связывает рождение методологии Scrum с проектом по разработке аналитической системы «Страж» (Sentinel), выполняемым компанией Lockheed Martin по заказу ФБР. Сазерленд пришел на проект, когда дата завершения была просрочена на один год. Из выделенных из бюджета США 451 000 000$ было потрачено почти 90% и реализовано только около половины требований. По оценке тамошних экспертов, на завершение проекта требовалось еще 350 000 000$ и десять лет работы. При этом необходимость разработки системы «Страж» была продиктована провалом проектов ФБР по созданию систем «Автоматизированная поддержка следственных дел» (Automated Case Support, ACS) и «Виртуальные следственные дела» (Virtual Case File, VCF), работа над которыми стоимостью 170 000 000$ длилась без малого тринадцать лет. Вам эта ситуация ничего не напоминает?
А я то, простофиля, раньше думал, что для этого предназначен ГОСТ Р 2.105—2019... Ну или на худой конец ГОСТ 19 серии... А оказывается чтобы стандартизировать стиль проектной документации эти книжки вообще не нужны...
Действительно, зачем нужен капитан на нашем паруснике? Зачем нужна карта? Да и штурман лишний. Ведь он не лазит по вантам. Да всех офицеров давно нужно за борт! Сверхпродуктивная команда сама разберется что к чему...
А Вы, я смотрю, пессимист реалист... Однако, и в Вашем комменте делается вывод о необходимости формирования отчетности об актуальном состоянии программного проекта. Вслепую управлять не получится. Создание информационной модели объекта исследования/управления - один из ключевых моментов RnD. В современных учебниках по менеджменту об этом вообще не говорят. Вопрос как это сделать максимально эффективно? Об одном нетрадиционном подходе к построению такой модели на своих программных проектах я рассказываю здесь. Надо отметить, что мои отчеты, которые автоматически формируются на основе этого подхода, зачастую не очень нравятся биг-боссам. Но зато эти отчеты позволяют адекватно оценивать текущее состояние проектов. И превентивно делать необходимые пинчищи управляющие воздействия.
Ответ на этот вопрос во многом зависит от самого проекта и его масштаба. Небольшой стартап? Канбан. Продуктовая разработка на этапе стабильных продаж? Scrum. Заказная разработка в интересах крупного российского корпоративного заказчика? ГОСТ 34. Заказная разработка в интересах крупного зарубежного корпоративного заказчика? PM BoK. Кстати ГОСТ 34 не запрещает прототипирование на любых этапах, в т.ч и на старте. Как мне представляется главное не превращать инструменты в догму. Неважно какого цвета кошка, главное чтобы она ловила мышей (с). Обратите внимание, что ГОСТ 34 на начальных этапах предполагает проведение научно-исследовательских работ в интересах обоснования требований и проработки методик сложных расчетов. Правда, как правило, этот этап никто не выполняет. Кроме того, разработка программного обеспечения есть в чистом виде разработка новых алгоритмов. Процесс получения новых знаний издавна называется научно-исследовательской деятельностью. Поэтому при управлении своими программными проектами я стараюсь придерживаться принципов изложенных в ГОСТ Р 15.101-2021 (обратите внимание на приложение А).
Кажется, что дебатах о неэффективности waterfall, все забыли, что чистого waterfall в природе никогда не существовало. Разве только в учебниках по программной инженерии. Даже в знаменитой статье откуда пошло это слово, автор применил его для описания крайней мифической ситуации которой надо всячески избегать.
Однажды, общался с детским психологом. Он проинформировал, что первые детские воспоминания фиксируются со времени когда ребенок начинает говорить. По моему личному опыту так и есть. Получается, вся осознаваемая память формируется на вербальной основе. Может просто мы не умеем осознанно пользоваться невербальной памятью?
Этот вопрос мне задала преподаватель математики, в IT-колледже, куда однажды я пришел в поисках потенциальных сотрудников для нашего программного проекта. И это послужило для меня поводом найти ответ. По крайней мере для себя. Нужно ли фигуристу бегать, прыгать на скакалке, отжиматься от пола и подтягиваться на турнике? Ведь этого всего он не делает, когда выходит на лед... А может ли он этого не делать совсем? Ответ зависит от результатов, которые хочет получить этот фигурист.
Конечно. Вы пришли в компанию прежде всего для того, чтобы достигать своих целей. И компания должна Вам помогать в этом. Кстати, как руководитель Вы должны обеспечить совпадение целей сотрудников своей команды и целей компании. По крайней мере в установленные периоды рабочего времени. Только вот для обезболивания своей кодилки, я бы рекомендовал придумать отдельный проект. В рамках автоматизации Ваших обязанностей например. Не решать задачи кодинга в проекте которым Вы руководите. IMHO, есть риск пока Вы не даете своей технике заржаветь, заржавеет команда.
Был интересный кейс. Представитель госзаказчика внимательно слушал все мои предложения по проекту и со всем соглашался. Я был просто счастлив от такого внимательного и понятливого слушателя. Результаты наших бесед я старательно протоколировал. Через некоторое время выяснилось, что он даже не пытался понимать то, о чем ему говорят. Он считал, что все мои предложения будут реализованы ВМЕСТЕ , а не ВМЕСТО бреда который требовало ТЗ. Он так и сказал: "А зачем я буду отклонять дополнительную функциональность которую вы предлагаете? Ведь от этого стоимость и сроки проекта не изменятся. А ваши протоколы наших совещаний только подтверждают то, что вы согласны это выполнить." Хороший урок. Для меня.
В Харькове киноконцертный зал "Украина" имеет форму гиперболического параболоида. Построен в 1961 году.
На мой взгляд в статье Вы прекрасно описали последствия, в случае если результаты таймтрекинга приравниваются руководством к результатам работ. Весьма распространенное заблуждение.
Однако, в своей деятельности я тоже пришел к необходимости таймтрекинга. Однако, в нашем случае таймтрекинг используется только для того, чтобы превентивно выявить риски и адекватно спланировать работу сотрудников так, чтобы не было переработок и срыва сроков. Как я пришел к такой жизни и как у нас в команде используются результаты таймтрекинга я подробно описал здесь и здесь. Буду рад конструктивной критике.
Можно почитать здесь и здесь. Надо отметить что в настоящее время правила в Школе 21 не такие жесткие как описаны в статьях. Например, пробовать поступать можно без ограничения возраста и количества раз.
Да, я в курсе, что Школа 21 франшиза Ecole 42. По слухам сейчас эту франшизу целиком перекупили американцы. Моя рекомендация основывается на личном опыте прохождения интенсива (бассейна) в Школе 21, более чем 20 летнего опыта в IT индустрии и более чем 10 летнего опыта преподавания в вузах. Поначалу, поступив на интенсив я хотел посмотреть изнутри на эту разрекламированную школу. Ну и хотел на уровне современных требований реанимировать свои навыки программирования, изрядно изуродованные работой на руководящих должностях. Я думал что со своим-то опытом, я легко пройду этот интенсив без отрыва от основной работы. Не тут то было. Уже в конце первой недели, я пришел к своему руководителю, рассказал о своем обучении и попросил чтобы меня "не кантовали" еще три недели. Это оказался действительно очень интересный челендж.
Да, действительно, ограничения по кодингу были, но как правило не жесткие, скорее рекомендации, если только того не требовало конкретное задание. Не забывайте, что это учебные задачи, на которых цель - обучить находить решения в нетривиальных условиях.
Институт Школа 21 не заменит. Однако, тем не менее, отличная практика для людей которые хотят связать свою жизнь с программированием.
Что интересно, на интенсиве который я проходил, втихую обучались несколько топ-менеджеров Сбера. Не относящиеся по своему основному роду деятельности к IT. Не с целями поступить в Школу, а только пройти этот интенсив. "Проплыть бассейн" - как говорили в Школе. И они старались изо всех сил. На равных с молодыми студентами. И на мой взгляд, действительно демонстрировали, что на свои должности были назначены прежде всего за интеллект.
На мой взгляд - супер практика со стороны руководства Сбера, направленная на повышение степени понимания топами внутренних механизмов IT.
Вместо монастыря вполне подойдет кампус Школы 21, если он есть в вашем городе. Там, кстати, начинают обучение именно с чистого C.
Это не туман. Это дым от горящего нашего танка, за которым до того как этот танк подбили и ехала самоходка. Рекомендую первоисточник - книгу Виктора Курочкина, который знал о чем писал не по наслышке. Книга еще более реальна.
И может на заставку стоит поставить кадр из фильма, а не игрушку-самурая?
Кстати, как пособие по действительно эффективному менеджменту в экстремальных условиях рекомендую посмотреть незаслуженно забытую дилогию "Красная площадь" и фильмы об адмирале Ф.Ф.Ушакове.
IMHO - Одну из причин выгорания очень здорово описал Андрей Тысленко:
tldr ?Сорри... Это не я .... Это Джефф Сазерленд...
Однако, я бы не был столь категоричен в отношении Agile. По моему убеждению Scrum копирует тактику диверсионно-разведывательных групп. И это неудивительно для тех кто хоть немного знаком с биографией Джеффа Сазерленда. Для выполнения задач спецназа в эти группы подбираются суперпрофессионалы. Они не заморачиваются с оформлением документации. Горизонт планирования не превышает нескольких дней. Они заточены на получение конкретного результата. Как говорится "Никто, кроме нас!".
И некоторые "гении" полагают, что эти, без иронии, суперпрофессионалы могут решить любые задачи... Если бы было бы так...
Однако, иногда наблюдая как фанатично некоторые мои коллеги-менеджеры пытаются внедрить в руководство проектами то, что они называют «scrum» и «agile», я задаюсь вопросом - а всегда ли оправдано применение спецназа?
Истории об одних из лучших спецназовцев средневековья - ниндзя (или синоби) - ушли в область преданий, после того как регулярные войска, по приказу Оды Нобунаги, взяли под свой контроль провинцию Ига. Прототип Евгения Таманцева из легендарной книги В. Богомолова «Момент истины» погиб зимой 1945 года в окопном бою при неожиданном прорыве танковой группы немцев. Хироо Онода, младший лейтенант войсковой разведки Вооружённых сил Японии, успешно вел диверсионную деятельность на филиппинском острове Лубанг в течении 32 лет! Но разве Япония вошла в число победителей во Второй мировой войне? Первый вывод: стратегические задачи решаются не спецназом, а регулярными войсками. Второй вывод: как только спецназ теряет свое главное преимущество - маневр - он превращается в простую пехоту.
И в этом случае нужны уже другие способы организации проектов.
Но ни один вменяемый военачальник не будет привлекать элиту для решения боевых задач, которые могут выполнить обычные подразделения. Высокий риск очень скоро безвозвратно лишиться всей этой элиты, при таком подходе, как правило, удерживает командование от таких необдуманных решений.
Вы можете мне возразить, что на программном проекте тоже могут быть безвозвратные потери. И я с вами соглашусь. Однако ответственность руководителя за безвозвратные потери на программном проекте и при ведении боевых действий несоизмерима. Поэтому непуганые менеджеры программных проектов, ошалев от невиданных перспектив увеличения производительности, о которых написано в книжках про Scrum, пытаются применять этот поход везде и всюду. А потом еще делятся на IT-конференциях и на Habr своим успешным проектным опытом о том, как можно эффективно забивать гвозди с помощью микроскопа...
Более подробно - в одной из следующих статей...
Джефф Сазерленд в своей знаменитой книге связывает рождение методологии Scrum с проектом по разработке аналитической системы «Страж» (Sentinel), выполняемым компанией Lockheed Martin по заказу ФБР. Сазерленд пришел на проект, когда дата завершения была просрочена на один год. Из выделенных из бюджета США 451 000 000$ было потрачено почти 90% и реализовано только около половины требований. По оценке тамошних экспертов, на завершение проекта требовалось еще 350 000 000$ и десять лет работы. При этом необходимость разработки системы «Страж» была продиктована провалом проектов ФБР по созданию систем «Автоматизированная поддержка следственных дел» (Automated Case Support, ACS) и «Виртуальные следственные дела» (Virtual Case File, VCF), работа над которыми стоимостью 170 000 000$ длилась без малого тринадцать лет. Вам эта ситуация ничего не напоминает?
А я то, простофиля, раньше думал, что для этого предназначен ГОСТ Р 2.105—2019... Ну или на худой конец ГОСТ 19 серии... А оказывается чтобы стандартизировать стиль проектной документации эти книжки вообще не нужны...
Действительно, зачем нужен капитан на нашем паруснике? Зачем нужна карта? Да и штурман лишний. Ведь он не лазит по вантам. Да всех офицеров давно нужно за борт! Сверхпродуктивная команда сама разберется что к чему...
А Вы, я смотрю,
пессимистреалист... Однако, и в Вашем комменте делается вывод о необходимости формирования отчетности об актуальном состоянии программного проекта. Вслепую управлять не получится. Создание информационной модели объекта исследования/управления - один из ключевых моментов RnD. В современных учебниках по менеджменту об этом вообще не говорят. Вопрос как это сделать максимально эффективно? Об одном нетрадиционном подходе к построению такой модели на своих программных проектах я рассказываю здесь.Надо отметить, что мои отчеты, которые автоматически формируются на основе этого подхода, зачастую не очень нравятся биг-боссам. Но зато эти отчеты позволяют адекватно оценивать текущее состояние проектов. И превентивно делать необходимые
пинчищиуправляющие воздействия.Ответ на этот вопрос во многом зависит от самого проекта и его масштаба. Небольшой стартап? Канбан. Продуктовая разработка на этапе стабильных продаж? Scrum. Заказная разработка в интересах крупного российского корпоративного заказчика? ГОСТ 34. Заказная разработка в интересах крупного зарубежного корпоративного заказчика? PM BoK. Кстати ГОСТ 34 не запрещает прототипирование на любых этапах, в т.ч и на старте. Как мне представляется главное не превращать инструменты в догму. Неважно какого цвета кошка, главное чтобы она ловила мышей (с). Обратите внимание, что ГОСТ 34 на начальных этапах предполагает проведение научно-исследовательских работ в интересах обоснования требований и проработки методик сложных расчетов. Правда, как правило, этот этап никто не выполняет. Кроме того, разработка программного обеспечения есть в чистом виде разработка новых алгоритмов. Процесс получения новых знаний издавна называется научно-исследовательской деятельностью. Поэтому при управлении своими программными проектами я стараюсь придерживаться принципов изложенных в ГОСТ Р 15.101-2021 (обратите внимание на приложение А).
Кажется, что дебатах о неэффективности waterfall, все забыли, что чистого waterfall в природе никогда не существовало. Разве только в учебниках по программной инженерии. Даже в знаменитой статье откуда пошло это слово, автор применил его для описания крайней мифической ситуации которой надо всячески избегать.
Однажды, общался с детским психологом. Он проинформировал, что первые детские воспоминания фиксируются со времени когда ребенок начинает говорить. По моему личному опыту так и есть. Получается, вся осознаваемая память формируется на вербальной основе. Может просто мы не умеем осознанно пользоваться невербальной памятью?
Этот вопрос мне задала преподаватель математики, в IT-колледже, куда однажды я пришел в поисках потенциальных сотрудников для нашего программного проекта. И это послужило для меня поводом найти ответ. По крайней мере для себя. Нужно ли фигуристу бегать, прыгать на скакалке, отжиматься от пола и подтягиваться на турнике? Ведь этого всего он не делает, когда выходит на лед... А может ли он этого не делать совсем? Ответ зависит от результатов, которые хочет получить этот фигурист.
Плюс за раздел <Какие ТЗ и требования я встречал>, ноль за остальную часть статьи.
Конечно. Вы пришли в компанию прежде всего для того, чтобы достигать своих целей. И компания должна Вам помогать в этом. Кстати, как руководитель Вы должны обеспечить совпадение целей сотрудников своей команды и целей компании. По крайней мере в установленные периоды рабочего времени.
Только вот для обезболивания своей кодилки, я бы рекомендовал придумать отдельный проект. В рамках автоматизации Ваших обязанностей например. Не решать задачи кодинга в проекте которым Вы руководите. IMHO, есть риск пока Вы не даете своей технике заржаветь, заржавеет команда.
Был интересный кейс. Представитель госзаказчика внимательно слушал все мои предложения по проекту и со всем соглашался. Я был просто счастлив от такого внимательного и понятливого слушателя. Результаты наших бесед я старательно протоколировал. Через некоторое время выяснилось, что он даже не пытался понимать то, о чем ему говорят. Он считал, что все мои предложения будут реализованы ВМЕСТЕ , а не ВМЕСТО бреда который требовало ТЗ. Он так и сказал: "А зачем я буду отклонять дополнительную функциональность которую вы предлагаете? Ведь от этого стоимость и сроки проекта не изменятся. А ваши протоколы наших совещаний только подтверждают то, что вы согласны это выполнить." Хороший урок. Для меня.