"Черные страницы Scrum", по версии Ивана Селиховкина

Публикация № 949714

Методология - Управление проектом

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

 

 

В последние годы я работаю в проектном офисе, где мы, в том числе, подбираем методологии для реализации на проекте и опираемся на самые распространенные подходы: проектный – PMI, продуктовый – Scrum, процессный – Канбан. И поскольку мы ответственный проектный офис, мы не просто играем в методологии, мы пытаемся ответить на вопрос, оптимально ли мы подобрали методологию для конкретного проекта. Мы их подбираем, пытаемся скоординировать, где необходимо. Заодно проверяем себя, пытаемся придумать критерии эффективности, чтобы оценить, удачно ли была выбрана методология, можно ли было выбрать другую – более оптимальную, не ошиблись ли мы.

Во время работы мы ориентируемся на ядро каждого подхода. Например, у PMI есть библия PMBoK, у Scrum – Scrum Guide, с Канбан – несколько сложнее.

И хотя мы читаем все книжки, которые написаны на эти темы, в том числе, авторами этих методологий, мы используем только ядро. То ключевое, что имелось в виду, что вкладывал автор, который придумывал подход.

Кроме того, вызов, с которыми мы сталкиваемся, – мы должны отвечать на запросы проектной команды, особенно это характерно для молодых IT-команд, которые хотят работать по современному Scrum вместо устаревших диаграмм Ганта. И нам надо уметь отвечать на вопрос, можем ли в данном случае работать по Scrum, почему, какие проблемы до этого необходимо решить. И мы ищем ответы на эти вопросы. Мы применяем подходы, комбинируем их.

 

Почему именно Scrum?

 Я выбрал тему про один их самых популярных Agile подходов – это фреймворк Scrum.

 

И сразу хочу обратить внимание, что эта статья - это не критика Scrum. Это перечень проблем, которые, с моей точки зрения, вы должны уметь решать. Либо вы знаете, как их решить, либо у вас могут возникать сложности, которые поставят под угрозу проект или вашу карьеру.

 

Итак, сложности, проблемы, с которыми нужно уметь работать, если вы хотите использовать Scrum  

 

Проблема 1. Scrum Guide противоречит Agile манифесту

Неожиданности в применении Scrum начинаются с Agile манифеста. Это прекрасное творение менеджерской мысли, прекрасная гуманистическая вещь утверждает, что люди важнее процессов, а готовность к изменениям важнее следования первоначальному плану. И прекрасно то, что с этим абсолютно все согласны. Я не встречал менеджера, который был бы не согласен с этим. Никто не говорил мне, что надо плевать на людей, надо отпускать полкоманды, надо позволить расстроиться заказчику, лишь бы процесс был нерушим. Я успел поработать в госсекторе и с военной приемкой, но даже в этих зарегулированных отраслях не было таких людей, кто бы сказал, что процессы важнее людей.

 

В теории можно представить себе такую историю, где-то в глубине “банкинга”, когда действительно процесс очень важен, потому что если вы его меняете, риски очень высоки. И тут действительно лучше пусть полкоманды уволится, чем нарушатся процессы. Ибо риски очень велики. Но в целом в абсолютном большинстве проектов все менеджеры, как бы они не работали – по Канбан или Scrum – все согласны, что люди важнее процессов. И это очень хорошо. Ведь упираться в первоначальный план, вопреки здравому смыслу, нелепо.

Тем интереснее, что на эту тему пишет Scrum. Для этого нужно дочитать так называемое исчерпывающее руководство по Scrum до конца, до последних страниц. Там есть такое заключение:

«Роли, артефакты, правила и события Scrum не подлежат изменению. …Если вы что-нибудь меняете, то полученный результат Scrum уже не является…. Scrum существует только в виде цельного фреймворка…»

 

Scrum явно говорит, что нельзя ничего выкидывать. Вы можете что-то добавить свое, если оно не противоречит букве или духу Scrum. Но если вы что-то выкинули, это уже не Scrum. Не используйте это слово, потому что вы применяете уже другой подход, который не может так называться.

Интересно сопоставить эти вещи: с одной стороны, есть Agile манифест, в котором люди и взаимодействие важнее процессов, а готовность изменений важнее планов, а с другой – Scrum говорит, что он существует только в виде цельного фреймворка. И как же они сосуществуют? Что же важнее?

 

Это кажется умозрительной проблемой. Но она оказывается важной, потому что из нее вытекают другие проблемы, связанные с применением Scrum.

И сложность, которую надо понимать, – Scrum Guide не совсем соответствует Agile манифесту, в том числе, благодаря вышеназванным заключениям. Он очень жестко ставит рамки.

 

Вообще Scrum Guide – самый жесткий из всех фреймворков, которые я знаю в управлении в принципе. Подходы в традиционном проектном управлении гораздо мягче.

 

Проблема 2. Нет возможности удовлетворить потребности заказчика

Основа Scrum – абсолютная вера в то, что крайне важно раннее вовлечение заказчика. «Держать руку на пульсе» – это важно для заказчика, это большая ценность. Мы его вовлекаем, мы даем ему частый прирост полезной эмоциональности.

Знаете эту картинку? Ее очень любят сторонники Agile.

 

Понимаете, в чем здесь проблема? В том что это невозможно.

Это картинка буквально говорит нам: «не заставляйте заказчика долго ждать автомобиль, дайте ему что-то полезное, дайте ему сначала самокат, потом велосипед, потом мотоцикл, потом машину». Но нет ни одного способа из мотоцикла сделать автомобиль! Это технически нельзя, это разные продукты. Надо выкинуть мотоцикл и сделать с нуля автомобиль. Ничего нельзя взять из самоката, чтобы превратить его в велосипед. Там нет ни одной полезной детали, это абсолютно другой продукт.

Пример из моей жизни. Мы делаем медицинский сервер, который должен хранить медицинские изображения. Он умеет принимать данные томографа, складывать их и отдавать по запросу. И для заказчика важны следующие вещи: стабильность работы, масштабируемость и низкое энергопотребление. Нет никакой возможности дать заказчику кусочек сервера. Сперва сервер, который имеет только принимать данные, потом сервер, который умеет принимать и отдавать данные, потом сервер, который может их сортировать, а потом сервер, который работает энергоэффективно и надежно. Заказчик будет ждать сервер до тех пор, пока мы не дадим ему нормальный сервер. Никакие «наполовину прожаренные булочки» его не устроят.

 

Это кажется маргинальным примером, но таких очень много в IT-проектах. Scrum хорошо работает в тех случаях, когда у вас много пользовательской функциональности, когда вы делаете, например, интернет-магазин или мобильную игру и можете постоянно добавлять какие-то кнопочки, каких-то персонажей, и каждый прирост полезен, и заказчик может пользоваться промежуточными вариантами. Но если в вашем проекте большой бэкэнд (backend) или требуется очень тщательное проектирование, и это занимает огромную часть проекта, выкинуть которую никак нельзя, то Scrum, скорее всего, будет не за что зацепиться.

Вывод, который мы сделали: проверяйте себя. Если продукт, который вы собираетесь делать, содержит много пользовательской функциональности, тогда Scrum может быть применим. Если же у вас что-то похожее на наш сервер, и вы сперва долго работаете, а потом выдаете значимый элемент, и промежуточные части не важны, тогда Scrum подойдет гораздо хуже - ему просто не за что будет “зацепиться”.

Знаете фразу: «Нельзя построить мост по Scrum»? Так вот нельзя построить мост по Scrum! Заказчику нужен мост целиком. Никакие половинки и четвертинки или просто сваи ему не нужны, он не может их использовать. Поэтому нужно проверять себя, сколько у вас полезной функциональности, годится ли здесь продуктовый подход такого рода или нет.

 

Проблема 3. Невозможно оценить сроки

Еще одна проблема, с которой мы столкнулись, и вы должны уметь ее решать, если хотите, чтобы Scrum работал. Это оценка сроков. 

Коллеги, сейчас я расскажу очевидную для многих вещь. Но мне важно это сделать, чтобы подвести вас к проблеме. Как Scrum работает со сроками? Он отвергает экспертные оценки, он считает, что попытка прогнозировать сроки в IT – это всегда самообман, это химера, какая-то выдумка. И Scrum говорит, не надо пытаться придумать, сколько работа длится, надо померять это по факту: мы поработаем, увидим и вместо гипотез будем пользоваться фактами. И такой способ оценки сроков будет точнее.

Как это выглядит на практике? Scrum собирает у заказчика все его пожелания («хотелка» 1, 2, 3) и складывает их в некое условные «ведро» под названием backlog. Я очень упрощаю, но смысл такой. Затем мы находим самую простую задачу, наименее трудоемкую, и, вместо оценки сроков, спрашиваем себя, какова ее трудоемкость. Этот показатель у нас будет условной единицей трудоемкости. Это так называемый один условный стори поинт (story point). Потом мы оцениваем, какая трудоемкость у соседней задачи. Например, она вдвое более трудоемкая, чем самая простая. Тогда ее оценивают в 2 стори поинта. А еще есть задачи, у которых 3 стори поинта, 4 стори поинта. Найдется еще задача, которая будет такой же простой, как самая легкая, и ей тоже присвоят оценку в 1 стори поинт. И так мы продвигаемся по всем «хотелкам», все их оцениваем, а каждая получает оценку в стори поинтах.

Дальше мы идём работать. В Scrum важна ритмичность, поэтому мы решаем идти двухнедельными спринтами. Сколько задач мы можем «переварить» за 1 спринт? Мы не знаем. Как это определять? На глаз – методом, так называемого, комсомольского прищура. Вы прикидываете, что, наверное, 5 стори поинтов будет нормально, берете задачи на 5 стори поинтов и всей командой работаете 2 недели.

Допустим, с большим напряжением вы справились. Так выяснилось, что задачи на 5 стори поинтов вы можете закрыть за спринт, но это очень тяжело. В следующий спринт вы берете меньше задач, например, в 3 стори поинта суммарно. И очень легко с ними справляетесь. Но это тоже плохо, потому что осталось свободное время после спринта.

В очередной спринт вы берете, скажем, задач на 4 стори поинта и справляетесь довольно спокойно. И когда вы поработали 2-3 спринта, вы можете подсчитать так называемую мощность команды (velocity). Это не скорость, а именно мощность – сколько вы  можете «переваривать» задач за спринт.

На это нужно именно 2-3 спринта. Никакой один калибровочный спринт вам не ответит нормально на вопрос о сроках исполнения проекта. Вам нужно несколько раз попробовать, только тогда вы поймете на самом деле, какая мощность.

Что дальше делает Scrum со сроками? Он спрашивает себя, сколько осталось не отработанных задач. Допустим, на 30 стори поинтов. Если наша velocity находится где-то между четырьмя и пятью, возьмем пять, чтобы команда работала в высоком тонусе, значит, с задачами мы справимся за 6 спринтов. Зная, сколько длится спринт, мы можем сказать, когда закончим проект.

Это называется диаграмма сгорания. Ее можно нарисовать и понять, какие у нас сроки. Это то, что предлагает Scrum.

Еще важно понимать: velocity – это командный показатель. Это тоже философия Scrum, где очень важно чувство локтя, чувство плеча, взаимовыручка. Scrum постоянно говорит нам, что команды являются самоорганизующимися. То есть если мы подходим к завершению спринта и видим, что кто-то не справляется со своей задачей, то мы бросаемся ему помогать и дожимаем этот спринт, и обязательно укладываемся в сроки. Так  команда становится сплоченной и самоорганизующейся, развивается и так далее.

Так работает Scrum, поэтому velocity меряет обязательно команду, а не человека. Если вы начинаете втихаря мерить velocity каждого человека, это убьёт ту самую командность.

Представьте, я инженер. И вдруг я понимаю, что какой-то менеджер меряет мои задачки, мою производительность. У меня как минимум появляется вопрос, а нужно ли помогать коллеге. Если я пойду ему помогать, он свои задачки закроет, я справлюсь хуже, мои метрики упадут.

Поэтому Scrum категорически не поощряет индивидуальные метрики. И velocity – эта командная метрика.

И вот проблема: вы потратили 2 - 3 спринта, а обычно спринты не меньше двух недель (мало кто использует недельный спринт), померяли velocity, прикинули, какие могут быть сроки завершения проекта. И в этот момент, скорее всего, произойдет что-нибудь такого плана: кто-то из сотрудников уволился, кто-то ушёл в отпуск, кто-то приболел. Или у вас новичок в команде появился. То есть изменилась ваша команда. Временно или навсегда. Вопрос: какая у вас velocity на следующий спринт? Неизвестно! Вы этого не знаете. Это же метрика командная, а команда только что изменилась. Что нужно, чтоб понять velocity? Конечно, поработать еще два-три спринта, т.е. месяц-полтора. Тогда вы снова ее нащупаете.

 

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

Может быть, у вас исключение, и ваша команда не меняется, она стабильная. И velocity у вас не прыгает. Но практика показывает, что чаще всего velocity прыгает у всех, а значит, все время будет колебаться ваша диаграмма сгорания.

Проблема Scrum в том, что он почти никогда не позволит вам нормально предсказывать сроки. Вы все время будете додумывать, придумывать, не сможете положиться на ту метрику, которую вам предлагают по умолчанию. Потому что команда изменчива, а вы меряете только командную velocity, а она меняется.

 

 

Что с этим делать? На самом деле достаточно просто понимать, что Scrum никогда нормально не может спрогнозировать сроки окончания разработки. К счастью, на многих проектах это неважно. На многих проектах сроки ставятся умозрительно – из серии, заказчик сказал, что «хотелось бы к декабрю закончить». Этот срок он взял из головы, и с ним можно договориться. Но если у вас есть жесткий срок, он определён каким-то неизменным контрактом или привязан к чему-то объективному (у заказчика что-то случится по истечении этого срока), и не может быть сдвинут, тогда Scrum использовать тяжело. Он никогда не может нормально предсказывать сроки окончания. Там это никак не сделать.

 

Проблема 4. Ваша команда не кроссфункциональна

Еще одна сложность Scrum в том, что ваша команда наверняка не кроссфункциональна, как бы вам не казалось обратное.

Что вообще такое кроссфункциональность? В Скрам-гайд сказано:

«СкрамR08;команды являются самоорганизующимися и кроссфункциональными» (стр. 5).

И: «Кроссфункциональность – наличие в рамках команды всех необходимых навыков для командного создания Инкремента Продукта» (стр. 7).

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

 

Второй способ, как обычно все понимают кросс функциональность, – это когда в команде есть все нужные роли: есть и аналитики, есть и те, у кого лучше программирование получается, и тестирование, т.е. команда в целом обладает всем нужным набором, чтобы делать продукт. Сориентируемся именно на втором варианте.

В Scrum есть такое пояснение: разработчик – это единственная роль в команде разработки, и другие роли в команде разработки не признаются. А если дальше посмотреть Scrum Guide, то там написано, что подкоманды делать в нем нельзя.

 

Как вы помните, выкидывать из Scrum ничего нельзя, иначе это не Scrum. Пока помним про этот абзац, но не будем в него вдаваться.

Давайте сконцентрируемся на варианте, когда кроссфункциональность – это наличие в целом такой команды, которая может сделать все, что надо. Представим, что в ней есть только три простые роли: (обычно в командах больше ролей) аналитик, разработчик и тестировщик. Это совсем простой пример.

 

Как они делят между собой полномочия внутри спринта? Начинается спринт. Мы взяли какую-то «хотелку» заказчика в реализацию. Первое, что нужно сделать, – включиться аналитику, он задачи прорабатывает и передает дальше. Он начинает работать (у него красные глаза), а остальные пока ждут.

 

Аналитик поработал, по мере его работы появляются какие-то постановки, спецификации. Тут подключается разработчик.

 

Разработчик начинает работать (теперь уже у него красные глаза), спринт идет дальше. Аналитик, тем временем, немного отходит от дел, потому что свою часть работы сделал.

 

Со временем просыпается еще и тестировщик.

Он принимает от разработчика задачи, и под конец спринта уже в основном работает тестировщик (до красноты глаз). Периодически он возвращает разработчику какие-то дефекты, их правят, иногда вместе ходят к аналитику, если оба не поняли задачу.

 

То, о чем я рассказал, – бред. Потому что треть спринта «спит» каждая из ролей: в конце не особо нужен аналитик, а в начале не особо нужен тестировщик и разработчик, им делать нечего. Но это абсурд.

Что делают многие команды? Очень часто они запускают как бы аналитика с опережением. Как это может выглядеть? Аналитику предлагают работать заранее, чтобы он шел на 1 спринт вперед, прорабатывать задачки. И тогда разработчику будет, что делать. Попробуем представить себе это. Аналитик включается на 1 спринт раньше, берет задачки, делает по ним постановки, работает по ним с какой-то своей мощностью. На спринт позже просыпается разработчик. И у него уже всегда есть работа. Принимая задачки от аналитика, он работает с какой-то своей velocity.

Важно, что мощность разработчиков - это уже другой показатель, это как бы другая команда (1 или несколько разработчиков), и у них своя velocity, они могут работать быстрее аналитика или медленней. Нам нужно тоже ее померять, чтобы понимать, насколько нужно с опережением идти аналитику. Видимо, еще на 1 спринт позже подключается тестировщик, который принимает от разработчика задачки и тестирует их со своей velocity.

Это только три роли, а представьте, если их больше. Понятно, что это опять бред.

Каждый, кто так делал, понимает, что рано или поздно произойдет: споткнется аналитик и повалится вся схема. Например, он не успеет дать задачки разработчику, и у них у всех не будет работы. Более того, мы только что сильно усложнили подход. У нас есть теперь три команды, и у каждой своя velocity. И вообще все это подозрительно похоже на диаграмму Ганта, которую мы так не любим.

 

 

Сейчас полезно вспомнить тот абзац, про который мы говорили раньше: разработчик – единственная роль в команде разработки, других Scrum не признаёт. 

Отсюда вывод, который мы сделали для себя: кроссфункциональность – это в прямом смысле слова, именно в первом смысле слова, когда все умеют всё. Scrum без костылей и без лишних вопросов работает тогда, когда у вас действительно все члены команды могут всё: разработчик может и протестировать, и выступить аналитиком, и дизайн немного запилить, если нужно. Вот тогда понятно.

Что делать? Одно из двух: либо спросить себя, является ли наша команда на самом деле кросс функциональной (так бывает, но редко), либо придумать свой способ решения проблемы переключения ролей.

 

 

Как ее еще пытаются решать? Аналитика, например, выносят вообще из Scrum команды, чтобы он работал с задачами  на уровне backlog’а. Тестировщика пытаются заменить автотестами. Но это тоже не очень просто, на практике еще миллион вопросов возникает.

 

Проблема 5. Слишком много времени на планирование

Одна из ценностей Scrum, особенно если верить книжкам, которые написал один из авторов Scrum Guide, – Scrum экономит время на планировании. Команда не тратит время на то, чтобы делать планы в начале, а сразу идет работать. Но давайте посчитаем, сколько на самом деле уходит времени на планирование в Scrum.

Представим себе недельный спринт. Что такой недельный спринт? Это 5 рабочих дней, 5 прямоугольников.

 

На что тратится время при планировании Scrum? Во-первых, в Scrum есть планирование спринта. Если бы спринт был месячный, то планирование должно было бы занимать не более 8 часов, а он у нас недельный. Согласно обтекаемой формулировке Scrum Guide, если спринт короче, то на его планирование нужно меньше времени. Насколько меньше, непонятно. Но на практике очень мало команд может планировать спринт быстрее чем за три-четыре часа, это в среднем.

 

Есть еще так называемый ежедневный Scrum. Так называемый стендап - очень полезная практика, когда в начале каждого дня все члены команды собираются и отвечают на три вопроса (условно):

- что я делал вчера?

- что я буду делать сегодня?

- чем мне можно помочь?

На это уходит не больше 15 минут в день. В 15 минут не так-то просто уложиться, но это достижимо. Если возникают вопросы в ходе ежедневного Scrum, то они переносятся на отдельное совещание: специалисты, которых касаются проблемы, остаются и между собой все обсуждают. Они тратят на это столько времени, сколько нужно – 40 минут, 50 минут, сколько потребуется.

 

На что уходит время еще? Есть такая вещь, как обзор спринта и ретроспектива. Обзор спринта в месячном спринте занимает не больше 4 часов, а ретроспектива – не больше 3 часов. Если бы спринт был месячным, то на ретроспективу и обзор ушел бы целый рабочий день – 7 часов. В нашем примере он не месячный, но опять же по нашему опыту, быстрее, чем за три-четыре часа и обзор, и ретроспективу провести сложно.

 

 

Но и это еще не все. Еще есть такая вещь, как уточнение backlog’а, которая может занимать до 10% времени от всего свободного времени команды.

 

 

А теперь давайте посчитаем, что получилось на нашем недельном спринте:

- планировать спринт – полдня в неделю;

- ежедневный Scrum, если все дни сложить, это 0,15 дня за всю неделю в сумме;

- вопросами, которые требуют обсуждения, мы пренебрежем, посчитаем, что их не было, и мы потратили 0, хотя на практике будут такие вопросы, и мы на них время потратим;

- на обзор и ретроспективу ещё полдня в неделю;

- еще примерно полдня в неделю на уточнение backlog’а.

В сумме получается 1,65 дня, то есть 30% рабочего времени. Столько уходит на планирование недельного спринта.

 

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

Но если у вас принят месячный спринт, там другие проблемы. Вы же обещали заказчику вовлечение, частые поставки, где же они? Раз в месяц? Scrum отбирает у заказчика возможность прогнозировать сроки, но зато дает ему вовлечение, «руку на пульсе» и частые поставки – регулярно. Но раз в месяц – это не частные поставки. Любой  проектный подход запросто обеспечит ежемесячные релизы. Тут Scrum уже ни при чем. Поэтому  месячные спринты – тоже не очень популярный подход. В основном используются двух-трехнедельные спринты, и там у каждого свои особенности. И там тоже довольно много времени уходит на планирование.

 

Что с этим делать? Просто понимать, что Scrum – это один из очень прожорливых до времени на планирование фреймворков. Если проектные подходы тратят много времени в начале и не очень много – в процессе, то Scrum очень много времени тратит на планирование постоянно.

 

Другие проблемы Scrum

Коллеги, есть ещё множество проблем. Например, если ваша команда уже сейчас не является высоко эффективной и дружной, то, по нашему опыту, применение Scrum и всякие коучи не сделают ее более эффективной и дружной. Дело в том, что у вас сначала должна быть дружная команда, и тогда отлично зайдет Scrum. Первична именно команда, а не фреймворк.

Также вам всегда будет хотеться, чтобы владельцы продукта были немножко получше, немного покруче. Это проблема не человека, это проблема того, что роль слишком перекручена. На нее возложена функция троих человек, как минимум. Такие универсальные люди в природе почти не встречаются. Поэтому всем всегда не нравится их владелец продукта, кажется, что нужен человек посильнее, и будет меньше проблем.

 

В рамках этого доклада я не успеваю рассказать, почему Scrum не нравится финансистам, и почему он незаметно проталкивает вам консалтинг. Все это вынесено в отдельную статью, которую можно почитать по ссылке.

 

 

И еще раз подчеркну: это не критика подхода. Это предупреждение. Есть проблемы, о которых вы должны знать, и должны понимать, в чем они заключаются. И вы должны знать способ, как вы преодолеете их: для каждой нужно сформулировать свое решение. Тогда Scrum можно применять смело.

 

 

 

В завершение скажу: мы применяем Scrum. Просто это не так легко и не так безопасно, как кажется иногда.

*******

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие.

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. user1096347 24.11.18 14:35 Сейчас в теме
Все эти проблемы довольно распространены, на любом качественном тренинге по скрам о них говориться, как и о том, как их решить, конечно же, тоже. :)
Vladimir Litvinenko; +1 Ответить
3. user1096704 25.11.18 13:34 Сейчас в теме
(1) автор ведь не говорит, что решений нет. Он говорит, что решения есть, но они не являются частью кошерного скрама)) и решения эти известны и без ваших тренингов и аджайл-наклеечек
Автору респект и плюс 100 к карме за то, что все баги в одном месте собрал. Обычно спорить лень с последователями Великого и Могучего Гудвина Скрама, теперь их можно к этой ссылке отправлять ;)
DonAlPatino; LordKim; +2 Ответить
2. Vladimir Litvinenko 24.11.18 16:08 Сейчас в теме
Отличная публикация, хорошо отрезвляет.

И подтверждает, что быть в команде, способной работать по Скраму - большая удача. В коллегах найдем высокую эрудированность. И низкую “токсичность”, как автор назвал демотивацию к работе над продуктом в целом, вместо куска кода над которым приказал работать начальник.


Лично мне приятно работать с людьми, которые не только способны написать кусок кода, который "ну работает же" , но и интерфейс проработают хороший. И проверить качество своего решения и решения коллег способны. Иначе говоря, способными быть чуть-чуть дизайнерами и хорошими QA.

По наблюдениям подход к написанию кода, проверке качества и подход к проектированию интерфейса очень коррелируют. Если в интерфейсе бардак, то и код, даже выдающий результат, окажется неподдерживаемым набором костылей написанным для себя-любимого, а не для команды. С аргументацией, что стандарты написания кода и проектирования интерфейса нарушают тонкую творческую натуру и замедляют разработку )) “Мы же не фирма 1С чтобы им следовать”. И внедрённое решение становится кандидатом на перевнедрение. При этом руководители будут долго питать иллюзии что продукт в порядке, а потом окажется что за вырезание скрытых метастаз никто уже не хочет браться. И придется с рынка набирать программистов у которых просто нет выбора куда пойти и они готовы и с таким бардаком работать.


Книгу тоже прочитал.

Она выдержана в более резком и запугивающем формате, чем выступление. В целом недостатки скрама для команд с низкой мотивацией справедливо расписаны. Но чувствуется, что у автора больше опыта и знаний о возможных решениях, которыми он бы мог поделиться. В то же время сеансы “запугивания” заканчиваются словами “подумайте над этим сами”. Хотелось бы больше информации.



Хотелось бы еще пару заметок сделать, может быть они покажутся полезными.


QA. Оно же тестирование.

Частые примеры с тем, что именно разработчик при нехватке ресурсов на тестирование начинает участвовать в тестировании, а не наоборот QA начинает разрабатывать, связан во многом с тем, что обычно компании экономят на QA.

В качестве примера, на текущем моем проекте более 10 разработчиков-кодеров и только 2 инженера QA. Считается что тестировать должны консультанты, которые увы не могут сделать это качественно и всесторонне. Качество очень низкое, руководство начинает метаться между скрамом, водопадом и просто плеткой.

При такой ситуации считаю правильным, когда кодеры перестают считать себя набивателями сине-красных букв и хоть немного погружаются в понимание того, что есть интерфейс и что есть поиск ошибок. Сложно с этим.

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



Velocity - мощность команды

Пример с увольнением, болезнью, отпуском не совсем корректен в качестве недостатка гибких подходов.

Если вы оцените работу в часах по любой другой технологии и кто-то из разработчиков заболеет или уволится или уйдет в отпуск (такой пример приведен в выступлении и в книге) то оценка ведь также будет неточной. Причем здесь скрам или любая другая технология? Вы можете хоть на голове стоять вместо применения скрама, применять любые проектные подходы. Увольнение сотрудника или всей команды в любом случае приведет к срыву сроков, если нет запасной команды.

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


Мощность (velocity) не нужно знать с точностью до десятых часа/сторипонинта. К чему это вообще? Если у вас 5 разработчиков и один из них заболел понять какой будет мощность на следующий спринт и сильно ошибиться сложно. Для этого нужно совсем не знать свою команду. Вы же знаете, сильный это разработчик ушел на больничный или джуниор. Оцените примерно. Даже если ошибетесь на 10%-20% это не фатально, чтобы записывать в жуткий недостаток инкрементального подхода.

И целью спринта является не обязательное решение всех задач взятых в спринт, а выдача готового к использованию инкремента. Такого, который удовлетворяет критерию готовности как с технической , так и с пользовательской точки зрения. Для этого и сказано о необходимости формулировать цель спринта, которая отвечает на вопрос, почему бы разработчикам не разбрестись каждому в свою комнату и не кодить по отдельности.

Это делает спринт - мини проектом (почти по водопадной модели!), а не просто двухнедельным индивидуальным забегом по хаотично набранным задачам из таск-трекера.

Кто-то формулирует цель спринта при планировании чтобы сделать его мини-проектом? Или напрягаться не хочется и слишком лень это делать? )))



Фрейморк - жуткое непереводимое слово

Пожалуйста, хватит уже страдать англофобией. Слово фреймворк - шикарно. И очень хорошо применимо в IT. Оно понимается как набор ограничений и инструментов. Почему “фреймворк Spring” и даже “фреймворк - платформа 1С” в вакансиях от самой фирмы 1С не вызывает взрыва мозга, а “фреймворк Скрам” вызывает англофобию и топанье ногами? Ууух…. страшные иностранные слова….. То ли дело наш тёплый ламповый желтый мир , где всё понятно и мы уже такие опытные )))

Если мы не собираемся строить мост по скрам, а применяем его в ИТ , то слово фреймворк можно и нужно применять.


Противоречие Agile подходу

Скраму 30 лет. Подход зародился примерно за 15 лет до того, как появился Agile-манифест. И да, его уже потом притянули к Agile за его итеративность и декларируемую необходимость часто взаимодействовать с заказчиком. В скрам-гайде нет ни одного упоминания про Agile, что становится открытием для многих и причиной стремления изобрести "свой правильный скрам"

(Здесь должна быть отсылка к публикациям Ивана Белокаменцева)

История конечно мало кому интересна, а жаль.

И действительно Agile - это очевидные вещи про гуманизм. Скрам - это жесткий понятный подход и правила. Чем он и ценен, так как приводит в Agile регулярный менеджмент и делает его более надежным и предсказуемым.



Канбан

На слайде под ним стоит большой черный вопрос. А материалы ведь есть - имена, явки, пароли, руководства. В последнее время несколько раз приходилось делиться ссылкой на уже старенький материал : https://youtu.be/lrDLbp0XeFA?t=287


А за статью еще раз спасибо!
FB_1811930315551820; Valerych; LordKim; +3 Ответить
7. FB_1811930315551820 27.12.18 14:32 Сейчас в теме
(2) Пока читал статью, набрасывал на листок тезисно возражения, чтобы потом ответить "системно"... После Вашего коммента все тезисы пришлось вычеркнуть, кроме одного:

И про планирование:
1. Возьмем самый распространенный срок спринта - 2 недели (1 - никто не делает, 3 - теряется та самая "вовлеченность" и частота релизов).
Планирование спринта - 4-5 часов (6-8 может быть в самом начале проекта, когда много отнимает стратегия)
Ретроспектива - 3-4 часа (хотя это уже не чистое планирование, но об этом потом)
Ежедневки - считать просто недобросовестно (давайте еще перекуры и кофе-паузы посчитаем)
2 недели = 80 часов, план+ретро = (7+12)/2=9.5 часов
Итого имеем около 12% затрат на планирование. В классике водопада - весьма эффективный результат (и по времени, и по стоимости)
Теперь о том, почему эти 12% раза в два эффективнее, чем те же 12%, потраченные в начале проекта.
В НАЧАЛЕ ПРОЕКТА ЗАКАЗЧИК НЕ ЗНАЕТ, ЧТО ИМЕННО ЕМУ НУЖНО! Весь мой скромный опыт говорит, что большая часть первоначальных планов идет в корзину. И потом ВСЕ РАВНО тратится время на перепланировку этих планов. Только проектом и графиком это уже НЕ ПРЕДУСМОТРЕНО! И тогда приходит он - всеми любимый песец аврал. И иногда мы даже укладываемся в график. Ну, то есть заваливаем сроки не так уж чтобы сильно. Вобщем, заказчик тоже человек, он же все понимает, тем более что сам и является основной причиной... И все довольны, все хорошо (если проект взлетел, конечно). Но простите, как же можно при всем при этом говорить, что "Ужасный СКРУМ скрумкал аж 30% от чистого рабочего времени нашего проекта"?? В ЛЮБОМ случае это время будет потрачено на планирование и перепланирование.
И теперь вишенкой на торте: про ретроспективу.
Если что-то на проекте идет не так - стопорится коммит понятного вроде функционала, или прототипы раз за разом не принимаются заказчиком - в любом случае надо уделить этому время, понять причину стопора и постараться ее устранить вместо того, чтобы "пробивать стену лбом". Введение плановой ретроспективы - всего лишь дань очевидной потребности соотносить свою деятельность с меняющейся реальностью. Так что по-хорошему, время на ретроспективу из "затрат на планирование" стоит убрать - ведь в идеальном случае "все идет по плану, проблем никаких" вся ретроспектива занимает минут 30 (а могла бы и меньше, но ведь каждому приятно похвалиться достигнутыми результатами). А в реальном случае "что-то пошло не так" - все время, потраченное на ретро, окупается с лихвой тем, что ценные ресурсы не сжигаются в тупую, потому что "мы ж так изначально планировали, не отступать, не сдаваться!". Вот и выходит. что НА ПЛАНИРОВАНИЕ у нас уходит не более 8% времени.
Vladimir Litvinenko; +1 Ответить
4. CheBurator 3422 26.11.18 17:00 Сейчас в теме
Полезно для меня.
Получил ответы на некоторые вопросы, по которым ощущал что "как-то не так оно"...
Спасибо.
5. Rico17 30 28.11.18 12:37 Сейчас в теме
Было бы намного полезней рассматривать "узкие места" в проектной деятельности (любых проектов?) в сравнении: PMI vs Скрам vs Канбан.
Сразу обнаружится, что это и правда "узкие места" ;)
6. DAV 05.12.18 11:10 Сейчас в теме
(5) Полезно голову включать, а не гоняться за модой. И делать проекты исходя из здравого смысла, а уж как это потом обозвать - дело маркетинга.
ЗЫ. Не примите на свой счет, это именно мое ИМХО. А рассматривать методологии противопоставляя их друг-другу? Что сравнивать, теплое и мягкое? Канбан - речь за процесс, Скрам - речь про продукт, PMI - речь про проект. И да, в водопаде есть еще PRINCE2 например, что же только PMI ограничиваться?
8. FB_1811930315551820 27.12.18 14:54 Сейчас в теме
(6) Согласен с тем, что здравый смысл - всему голова. Все методы и "фреймы" - всего лишь инструменты, а не серебряная пуля. И если ПМ ясно представляет себе задачу, предметную область вообще, и главное - соотносит все со способностями своей команды, то он практически интуитивно (на самом деле - на основе набитых ранее шишек, своих и чужих) должен понимать, какими инструментами надо воспользоваться здесь и сейчас. Нет такого ПМа - бедный, бедный проект...
Оставьте свое сообщение

См. также

Управление ИТ-проектами, базовый курс, 3 поток. Онлайн-курс с 15 мая по 1 июля 2019 Промо

Управление проектом Бесплатно (free)

Отличительная черта курса - органичное сочетание трех вещей: - Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С)  - Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days) - Разбор реальных проблем и рекомендации экспертов по проектам слушателей Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике  руководителей проектов внедрения. 

04.04.2019    12545    67    Infostart    18    

Управление в стиле Догвилль

О жизни Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    3205    0    1c-intelligence    15    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

Управление проектом Бесплатно (free)

Из-за отсутствия грамотных правил разработки на этапе внедрения сильно усложняется работа по поддержке и развитию типовых доработанных конфигураций. О некоторых правилах и подходах в разработке, которые помогут специалистам сопровождать внедренное решение, на конференции Infostart Event 2019 Inception рассказал разработчик компании «Инвестиционная группа Абсолют» Алексей Степаненко.

08.06.2020    3801    0    stepan96    12    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    4537    0    sapervodichka    1    

Ошибки управленцев: как топ-менеджеров убивает перфекционизм Промо

Управление проектом Бесплатно (free)

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    9480    0    user809424    11    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    9815    0    MariaTemchina    33    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

На самом деле, переход рабочей жизни в онлайн обладает некоторым количеством плюсов. В частности хочется верить, что формальный контроль “отслеживаем кто сколько часов проработал, проверка, что сотрудники на месте и все чем-то заняты” заменится фактической отчетностью “по результатам”.

23.03.2020    4898    0    MariaTemchina    24    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

Все, кто когда-либо работал в проектах, знают, как важна точность даваемых оценок длительности выполнения каждого задания. При этом, достаточно лишь одному заданию опоздать, чтобы поставить под угрозу выполнение сроков всего проекта. Стараясь подстраховать выполнение своих обязательств, мы закладываем в оценку длительности каждого задания изрядное количество резервов времени. Однако, как бы мы не старались, проекты все равно не завершаются в срок. И тому есть свои причины … четыре основные причины, почему проекты никогда не завершаются в срок.

03.03.2020    5628    0    VLikhobabin    44    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию очередную статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

29.06.2017    33470    0    1СERP    79    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Бесплатно (free)

В новой версии PMBoK традиционные рекомендации по управлению проектами перевернуты с ног на голову. В этой статье расскажу свою точку зрения, в чем, на мой взгляд, основные изменения, и как это может сказаться на проектах внедрения…   

23.01.2020    10896    0    MariaTemchina    8    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    5860    0    roman72    0    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    6313    0    1c-intelligence    32    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    30360    0    1СERP    175    

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Управление проектом Бесплатно (free)

Очередной темой серии статей “20 мыслей об ИТ-проектах” будут требования к системе. По результатам голосования был вариант про карьеру проектных ИТ-специалистов, но ее я коснулся в докладе на Воронежском митапе, немного изменив и сделав акцент в сторону аналитиков. В ближайшем выпуске сделаю небольшую выдержку по теме.

14.10.2019    5674    0    chavalah    16    

Незакрытый проект на 1000 часов

Управление проектом Россия Бесплатно (free)

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    11691    0    ogroup    163    

Стратегия выживания в корпоративных войнах

Управление проектом Бесплатно (free)

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    9072    0    GSoft    15    

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

Управление проектом Бесплатно (free)

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    31216    0    1СERP    189    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    10826    0    SergeyN    6    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

В идеале пользовательскую документацию надо создавать под каждый отдельный проект, менять и актуализировать ее, если в функционале что-то изменилось. Но чаще всего в организациях документацию считают неэффективной, поэтому даже не разрабатывают ее, либо документация имеется, но ее никто не использует, так как она устаревшая. Какие шаги надо предпринять, чтобы заинтересовать пользователей документацией и одновременно снизить нагрузку на консультантов 1С, рассказал руководитель службы технической поддержки в ГК «Доброфлот» Арсен Сазандрашвили.

20.08.2019    8139    0    KoldunOne    7    

Быстрый старт: минимальный набор автоматизации типовых процессов

Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Автоматизация дает множество преимуществ бизнесу, но в то же время ее выгода может быть настолько несущественной, что процесс принесет компании больше убытков, чем прибыли. С чего начать эффективную автоматизацию, какие процессы стоит автоматизировать на первом этапе, а какие – лучше оставить на потом, рассказала руководитель разработки систем учета компании «Едадил» Екатерина Золотарева.

16.08.2019    7834    0    Hissin    18    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

Недавно была написана статья о том, как работает мотивация персонала. Материал получил активный отклик у читателей Инфостарта, на форуме развернулась дискуссия, которая в итоге была достаточно далека от содержимого исходной статьи и свелась к критике самой идеи работы во франчайзи. Чтобы как-то ответить на эту критику, хотелось бы более подробно рассказать о том, что такое современный франчайзи и как он устроен. Но начнем мы с истории этого вида бизнеса, глазами рядового специалиста. Автор статьи Андрей Мироненко.

10.04.2017    31084    0    1СERP    107    

Управление проектами по автоматизации бюджетирования

Управление проектом Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) УУ Бесплатно (free)

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    7483    0    SergeyN    1    

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов

Управление проектом Бесплатно (free)

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    6375    0    sbase    9    

Цифровая трансформация. Будущее учетных систем

Управление проектом Россия Бесплатно (free)

О цифровой трансформации слышали все, но немногие в этом разбираются. Что она собой представляет, какие несет изменения, на что надо обратить внимание айтишникам и 1С-никам, рассказал на конференции руководитель департамента автоматизации строительных организаций компании «Первый БИТ» Иван Аверьянов.

19.06.2019    9621    0    FB_10160810658600104    62    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    41760    0    1СERP    231    

Риск - благородное дело!.. Часть первая

Управление проектом Бесплатно (free)

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    7150    0    MariaTemchina    8    

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения

Управление проектом Бесплатно (free)

В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

31.05.2019    8354    0    MariaTemchina    23    

Как мы со Стасом завод за 2 месяца автоматизировали

Управление проектом Бесплатно (free)

Мой опыт быстрого внедрения.

14.05.2019    10746    0    1c-intelligence    121    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Многие руководители предприятий не обладают полной картиной происходящего в собственных производственных подразделениях. Они знакомы с организационной структурой, направлениями деятельности, общими экономическими показателями. Если по результату получилась прибыль, то наступает уверенность успеха. Но есть ли на рынке предприятия, которые длительное время удерживаются в "слепом" режиме управления?

23.02.2017    27157    0    Gavrik    10    

Устав писать Устав

Управление проектом Бесплатно (free)

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    7174    0    MariaTemchina    8    

Как сжать время?

Управление проектом Личная эффективность 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    8669    0    1c-intelligence    39    

Путь джедая в управлении проектами 1С: умение быть, а не казаться

Управление проектом Бесплатно (free)

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    11106    0    MariaTemchina    15    

10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы Промо

Управление проектом Бесплатно (free)

Не так давно на одном из проектов во время инвентаризации была выявлена очень большая недостача. Как результат, одно из важнейших требований клиента по проекту было: разобраться с тем, что у него происходит в системе, и привести остатки, как он выразился, «в адекватное состояние». А незадолго до этого у меня в практике был случай, когда уже на второй день после внедрения качественной системы учета движения наличных денежных средств (кассы) также была выявлена недостача, но уже в кассе. И в первом, и во втором случае вину за возникновение проблемы представители заказчика попытались возложить на людей, которые занимались внедрением новой системы. И только после долгих и, надо признаться, довольно неприятных и очень эмоциональных разбирательств, удалось доказать клиенту, что система работает правильно, а виноваты в случившемся сотрудники компании, которые намеренно или ненамеренно создали фактическую недостачу товара и денег.

17.06.2016    39624    0    raiml    37    

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

Управление проектом Бесплатно (free)

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    7990    0    chavalah    22    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    9575    0    MariaTemchina    20    

Бизнес, не горюй

Управление проектом Бесплатно (free)

Про цели автоматизации.

04.02.2019    9717    0    1c-intelligence    64    

Практические вопросы внедрения и развития автоматизации склада Промо

Управление проектом Бесплатно (free)

Мне, как одинэснику, не приходилось заниматься какими-то узкими задачами «от сих до сих». Вся моя профессиональная деятельность, как одинэсника, была всегда связана с очень широким кругом вопросов. Наверное, потому, что я работал, в основном, в малых компаниях, где приходилось работать над всем спектром вопросов.

26.12.2014    44095    0    CheBurator    64    

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения

Управление проектом Бесплатно (free)

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

31.01.2019    8049    0    MariaTemchina    0    

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

Управление проектом Бесплатно (free)

Пользуясь несовпадением рождественских каникул в России и Германии, решила познакомиться с тем, как организована работа разработчиков в одном немецком банке. Сразу оговорюсь: еще давно, со времен совместных яхтенных плаваний с немцами, я противник четких стереотипов из серии "все русские всегда...." или "все немцы обязательно..." (пропущенные места предлагаю читателям заполнить самим в меру своей испорченности).

14.01.2019    9860    0    MariaTemchina    13    

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях"

Управление проектом Бесплатно (free)

Этой статьей начинается цикл из 20-ти обещанных мыслей об ИТ-проектах. Надеюсь, что по прочтении кто-то посмотрит на проблему незаменимых людей с другой стороны.

10.01.2019    12326    0    chavalah    123    

Практика пуска склада продуктов питания Промо

Бухгалтерский учет Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    35927    0    axxell    15    

Где мы взяли флакон?

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

История появления и развития методики

26.12.2018    9380    0    1c-intelligence    7    

Озарение после прочтения макулатуры по проектному управлению

Управление проектом Бесплатно (free)

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    9388    0    MariaTemchina    24    

20 мыслей об ИТ-проектах, или 20 лет спустя.

Управление проектом Бесплатно (free)

В этой серии из 20-ти статей я готов поделиться своей практикой управления проектами. Примеры, опыт и только то, что проверено лично. Выбираем темы голосованием!

09.12.2018    8810    0    chavalah    119    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Поговорить о том, какие причины способствуют гибели существующего и часто даже успешного на определенном этапе бизнеса, я планировал давно, но все не доходили руки. Но недавно я услышал о банкротстве моего, теперь уже, клиента. Именно этот факт стал для меня неким толчком. Я осознал, что именно сейчас, в условиях кризиса очень важно понимать, почему бизнес может окончиться крахом и учиться избегать подобных ситуаций. Как известно, когда в экономике кризис, любой бизнес ослаблен. Если сравнивать с человеческим организмом, то кризис для экономики – как ослабление иммунитета. Когда человек здоров, то мелкие болезни проходят незамеченными. Организм сам справляется с проблемами, а в случае ослабления иммунитета, любая инфекция может привести к серьезным заболеваниям или даже стать фатальной. Так происходит и в бизнесе. Если в период подъема экономики какие-то недостатки конкретного бизнеса сглаживаются, остаются незамеченными и даже не слишком мешают работать, то в периоды экономического спада они становятся теми самыми «тонкими местами», которые приводят к снижению прибыли, к определенным проблемам, а иногда даже к полному краху всего бизнеса.

06.04.2015    37420    0    raiml    14    

Памятка руководителя: не играйте с деньгами

Управление проектом Личная эффективность Управление персоналом (HRM) Бесплатно (free)

Важная статья о персонале из цикла «Памятка руководителя»: здесь я планирую затронуть один из наиболее острых вопросов – деньги. А также развернуто ответить на некоторые комментарий читателей по двум прошлым статьям.

05.12.2018    16630    0    andironenko    128    

Шаг назад и ... шаг назад (классификация внутренних проектов)

Управление проектом Бесплатно (free)

Во многих остросюжетных фильмах используется этот трюк. В начале фильма главный герой одиноко скачет по прерии лицом к хвосту лошади, или закопан в пустыне по самое горло, или какие-то не совсем добрые люди собираются отрезать ему то, что отрезать и не нужно. Потом идут титры, потом на весь экран спойлер: двумя неделями раньше... и здесь он хлещет виски в салуне, прикуривает от сто долларовой банкноты, рассекает на яхте с пятнадцатилетней капитаншей. Все то, что так не рекомендует делать Минздрав. И уже весь остальной фильм нам рассказывают, как можно собственно докатиться от такой до такой жизни. Такая же история приключилась и с прошлой статьей.

03.12.2018    8378    0    capitan    26    

Белая и пушистая рецензия на Чёрную книгу Скрам

Управление проектом Бесплатно (free)

Данный текст является ответом на "Черную книгу Скрам" Ивана Селиховкина. Честно скажу, несмотря на то, что рукопись вряд ли предназначалась моему взору, прочитала ее на одном дыхании.  Публикую рецензию как есть - свое имя автор, к сожалению, не написал.

26.11.2018    9689    0    MariaTemchina    40    

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

Управление проектом Бесплатно (free)

Говорить о внедрении программного продукта можно очень долго, тема это обширная, а нюансов в работе бизнес-консультанта очень много. В статье Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть I я раскрыл только некоторые общие понятия, пояснил, чем работа бизнес-консультанта для малого и среднего бизнеса отличается от работы обычных внедренцев. Также я рассказал о тех базовых принципах, на которых я строю свою работу по внедрению программного обеспечения. Сейчас я предлагаю перейти к подробному обсуждению процесса работы бизнес-консультанта при внедрении ПО.

16.11.2014    28477    0    raiml    46    

Черная книга Скрам

Управление проектом Бесплатно (free)

Наблюдения менеджера, разрушившего карьеру бездумным применением Скрам. Рекомендации и предостережения.

26.11.2018    7999    0    Selikhovkin    4    

Памятка руководителя: Будьте оптимистичным или на крайний случай злым

Блоги Управление проектом Бесплатно (free)

Следующая статья из цикла Управление персоналом - в этот раз предлагаю обсудить вопросы психологии управления и подчинения. Для тех, кто начинает читать этот цикл с этой статьи, вот ссылка на прошлый материал https://infostart.ru/public/937923/, в конце статьи будут ссылки на все статьи из серии «Памятка руководителя» - читатели просили. Итак, продолжаем работать с персоналом.

22.11.2018    12172    0    andironenko    43