История внедрения Scrum в отделе внутренней разработки 1С

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

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

Я работаю с 1С с 2004 года. В процессе своей работы я сменил несколько команд, и практически все они были командами внутренней разработки большого или среднего заказчика. В одной из команд (это был холдинг среднего размера) мы внедряли Scrum. Об этом я и хочу рассказать. Итак, мой доклад будет о внедрении Scrum. «Глубоких мыслей» не обещаю, просто постараюсь рассказать о том, как это было у нас, и возможно, пояснить, почему это было именно так

С чего все началось?

Что было в моей жизни до того, как я начал внедрять Scrum? 

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

Что у нас было на тот момент, когда мы начинали?

  • У нас была команда внутренней разработки – 4-5 человек.
  • Задачи к этому моменту уже «трекались». В качестве трекера мы использовали Mantis.
  • Документация для пользователей составлялась в Wiki.
  • Было понятие релиза.
    Несмотря на то, что у нас была внутренняя разработка, мы не имели доступа к базе. И значит, мы не могли залезть в базу и поправить, если что-то было не так. Мы выпускали релиз и выкладывали дистрибутив на внутренний открытый источник, а люди, которые сопровождали нашу базу 1С на филиалах (или на подразделениях холдинга), брали релиз оттуда. Получается, у нас было больше общего с внешней разработкой, потому  что, если находились какие-то баги, приходилось выпускать баг-фиксы и выкладывать новый релиз.
  • Был форум поддержки.
  • Также было несколько владельцев продукта (Product Owners). Это были заказчики так называемых профильных департаментов.

И был один руководитель (так называемый proxy-Product Owner), который собирал от них требования и выступал в качестве единого владельца продукта для нашей команды (собственно, так и рекомендуется в Scrum). 

 

Первые шаги

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

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

И оно завелось. На внедрении это было очень удобно: собраться стенд-апом у доски, постоять, подвигать эти тикеты, понять, что нам нужно сделать, что еще не сделано, в каком оно все статусе. Получалось нагляднее, чем это было в трекере, поскольку в трекере все лежало какой-то одной неподъемной кучей, а доска позволила нам как-то распределить наши задачи, расставить приоритеты. И, конечно, помогали дейли-митинги, которые мы проводили также у доски.

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

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

  • Вначале мы собирались у доски сами по себе, как программисты – это вызывало у руководства любопытство, но не более. Нас спрашивали: «А что вы делаете?» – «У нас дейли-митинг». – «Хорошо, занимайтесь, лишь бы задачи вовремя делались».
  • Но в определенный момент, когда появилась официальная поддержка сверху, это внесло определенные изменения, стало проще двигаться дальше.
  •  

Второй этап. Что изменилось?

У нас появилась электронная доска (мы сами ее сделали). Сначала нам специально выделили время и сказали: «Ребята, есть много продуктов по Scrum, Agile (например, Redmine, Jira), все поддерживается. Подберите себе что-нибудь для работы». Но мы, как настоящие 1С-ники, решили изобрести велосипед и сделали для этого свою конфигурацию.

Трекер никуда не делся (на рисунке показан наш трекер Mantis), но путь вопроса преобразился. Если раньше вопрос попадал в трекер и там же отслеживалось его состояние (плюс было какое-то обсуждение), то теперь стало немного по-другому. Трекер по традиции остался, туда собирались все требования, а в дальнейшем Product Owner принимал решение, пойдет требование в разработку или нет.

Если Product Owner решал, что требование должно пойти в разработку, то оно автоматически попадало в другой трекер, который мы назвали ScrumWork. Там расставлялись приоритеты, давалась оценка. 

Там была доска итерации, где мы могли перемещать тикеты. Многие инструменты для Agile также позволяют это делать.

Что еще поменялось в процессе? В форме тикета появились специальные подсказки, критерии готовности задачи. Например, мы ввели обязательное заполнение описания для первого демо, чтобы конкретизировать, как продемонстрировать решение для этой задачи.

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

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

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

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

 

Следующий этап. Поддержка

Доска менялась, становилась больше. 

Какая еще практика появилась?

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

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

И как только мы это сделали, все сразу рухнуло. Потому что разработчики начали брать эти красные тикеты, их пошло еще больше, все стало плохо, и мы стали думать, как сделать так, чтобы стало хорошо. И сделали.

Что мы сделали? Мы выделили одного разработчика, который занимался поддержкой. Но решили его менять по неделям. То есть, какой-то несчастный человек на неделю назначался в качестве саппорта. По возможности он брал задачи из основной итерации, но главным его приоритетом было решение вопросов по поддержке.

У несчастного на рабочем месте стояла большая красная машина (та, которая на картинке). И все знали, кто на этой неделе обречен общаться с пользователями и заниматься их сиюминутными проблемами.

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

Собственно, практика пожарного, дейли-митинги, доска.

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

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

 

Планирование

Дальше еще одна хорошая практика в Scrum, одна из самых главных, – планирование.

Собственно, ничего особенного про планирование сказать не могу. Оно проводилось классически:

  • На начало планирования Product Owner имел приоритезированный Backlog продукта, где у него набирались задачи на итерацию.
  • Для тех задач, которые еще не были оценены, выставлялась оценка с помощью Planning poker.
  • Что было интересного на планировании? Мы стали ставить на итерацию некую цель, имеющую определенную бизнес-ценность. Не просто «давайте за следующую неделю повесим как можно больше тикетов, и всем будет отлично». От генерирования огромного числа тикетов обычно никому отлично не бывает. Имеется в виду какая-то конкретная цель: внедрить блок учета конкретно для того-то или запустить давно желаемую «фичу» (что-то, что имеет ценность для заказчика). Это было важно для того, чтобы мы могли что-то показать заказчику на демо и соотнести поставленную цель с реальностью – выполнена она или нет. Я всем советую на планировании пытаться поставить цель итерации. Хотя надо сказать, что это не всегда возможно, особенно если делается большая «фича». Запустить «1/28 от этой большой фичи» – как цель звучит не очень хорошо. Но, конечно, бывало и так.

Теперь по поводу оценки. Оценка по методу Planning poker проводилась в неких условных единицах (в так называемых «попугаях»). При планировании мы договаривались, что за итерацию команда сможет сделать определенное количество этих «попугаев».

Вот здесь на слайде показаны наши реальные цифры:

  • Сначала мы вообще ничего не понимали, и там стоит прочерк.
  • Потом мы начали что-то понимать и определили, что оценка на итерацию у нас будет 80 «попугаев»,
  • Но уже на пятой итерации оценка упала до 34. Это нормально, потому что мы решили поменять систему оценок (стоимость единицы стала больше).
  • Потом запланированная стоимость наших итераций выровнялась и в последующем была плюс-минус одинаковой.
Правда, видно, что десятую итерацию вдруг оценили в 19 "попугаев". Но там стоимость оценки не поменялась, там изменился состав команды – людей стало меньше и, соответственно, на результат запланировано меньше часов.

 

Вот, кстати, очень простой калькулятор перевода «попугаев» в часы с помощью Excel. Потому что разработчики 1С любят все переводить в часы, к ним можно привязываться по оплате, а иногда без этого и невозможно. Смотрите, связываем «попугаев» с часами. Ничего военного:

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

Тут есть пункт Velocity – это стоимость одного Story Point («попугая») в часах по результатам предыдущей итерации. Соответственно, взяв эту стоимость, мы понимали, что при планировании следующей итерации мы можем взять задач на 54 Story Point. Мы старались брать немного больше (с запасом). Некоторые, наоборот, перестраховываются, берут меньше.

Соответственно, фактически в конце итерации мы понимали, сколько по факту было сделано (здесь 65). И, соотнося с реальными часами, проводили фактический расчет Velocity. У нас по факту получалось 0,12. Вот это вот 0,12 шло уже на следующую итерацию как планируемая скорость команды.

Вот таким нехитрым образом, понимая скорость, соотнося ее с часами, проводилась эта оценка.

 

Состав итерации

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

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

  • Демо. Во время демо ответственный за проект (так называемый архитектор проекта) становился, показывал, что в проекте поменялось. Даже если заказчика не было, демо проводилось «для себя», для того чтобы сама команда понимала, какие изменения произошли. И если кто-то всю итерацию пилил свою гайку, особо не обращая внимания на дейли-митинги и на окружающих, то на демо он имел возможность посмотреть, что же поменялось. И это было важно, в том числе для поддержки.
  • Дальше, после демо, проводилась ретроспектива. Мне вообще кажется, что ретроспектива для команды – это такая вещь в процессе, которую можно улучшать практически бесконечно. Сколько она у нас ни шла, я как Scrum-мастер ей никогда не был доволен. Хотелось, чтобы она проходила лучше, эффективнее, быстрее двигала процесс вперед.
    Какие сложности возникали на ретроспективе? Для нас, как для команды, которая изначально внедряла Scrum «снизу», обсуждение того, что у нас было в процессе сложного, плохого или хорошего, обычно выглядело так: «Ну вот, такая-то обработка была сложная». – «Нет, подожди, не обработка сложная, что в процессе было сложного? Или что можно улучшить?» С самого начала было очень тяжело объяснить, что ретроспектива – это не про код, а именно про сам процесс.
  • Code-review. Не буду долго останавливаться. Есть такая инженерная практика, когда из кода вычитываются определенные интересные места. У разработчиков друг в друга летят тонны конфетти – все же любят, когда его код вычитывают и критикуют.
  • И планирование. Поначалу, когда этих активностей не было, планирование занимало полтора дня: понедельник и часть вторника. Было тяжело, непонятно было, как это делать. А потом мы привели его в чувство, оно стало занимать полдня – все планируется, итерация набирается, приоритеты расставляются, заказчик доволен. Важное выполняется в первую очередь, неважное – во вторую. Все замечательно.
  • Конец итерации – это релиз. Какие-то абсолютно рутинные активности: собрать cf-ник, md-шник, выложить его, упорядочить. Все это делается в четверг, потому что все знают, что плохая примета выпускать релиз в пятницу, поскольку это испорченные выходные.
  • Ну и пятница – инженерный день. Это даже не из Scrum. Мы могли себе позволить какой-то день, отведенный под то, чтобы разработчик мог почитать мануалы, сделать какой-то прототип для следующей итерации, попробовать какую-то новую функцию или установить себе свежий релиз платформы 8.3, который пока заказчику не нужен, но можно что-то там для себя поковырять. Я не знаю, наверное, не все могут себе позволить инженерный день. Но мы могли, хотя это и дорого – это целый день работы программиста. Но считается, что в долгосрочной перспективе это очень полезно, на самом деле.

Вот такой у нас был состав итерации, так мы ее проводили.

 

Заключение

И вот… так у нас в конечном итоге стало (мне эта картинка самому очень нравится).

Раньше, когда разработчик брал и перевешивал тикет, он писал на нем свою фамилию - то есть тикет взял такой-то. А потом, через какое-то время, мы стали клеить вот такие аватарки. Взял вопрос – наклеил аватарку.

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

Вот такое личное, очень дорогое мне замечание.

 

***********

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

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

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. borodabmc 26.02.15 16:08 Сейчас в теме
Вкратце расскажу наш путь к Agile... За чашечкой чая в одно прекрасное утро подумали, что стало скучно работать в полном хаосе и пошли гуглить...
Начинали сначала с чистого "КАНБАНа". У каждого отдельная доска, только со своими задачами. Реализовали и на доске и в своей CRM. Аналитиками бросались задачи на конкретных разработчиков или в общую корзину. Вначале по правилу "кто первый встал, того и тапки", то есть кто-раньше поставил задачу, ту задачу быстрее брали в работу. Вначале все было достаточно хорошо. Но кампания росла, и в такой адаптации уже не помогало, а зачастую мешало работать. Стало не хватать адекватного планирования...(чтоб хоть банально закрыть вопрос со сроками, которые озвучивать заказчикам). В итоге прикрутили приоритеты к задача - тоже мало.
Начали внедрять Scrum со всеми артефактами (user story, спринтами, ролями, доской, и т. д.).
Тяжело было вначале донести людям (те, с которыми поднимали Канбан, давно слились), которые привыкли работать в хаосе и постоянно в режиме хотфикса... Пришлось даже пенделей отвесить некоторым: вроде собрались, замутили спринт, на выходе - спринт мертвый... почему... не понятно, чего от них хотят... Собрались, еще раз объяснил, что Scrum, в первую очередь, - это командная работа... Вроде прислушались... Второй спринт взлетел... В итоге работает несколько команд на проектах.
С дежурным хорошая идея, тоже пытался, чтоб был человек дежурный на второй линии поддержки, если первый уровень не справляется. Тяжело пошло... продукты разные, проекты тоже... (от розницы до автотранспорта)... и универсальных бойцов мало...
По итогу:
Scrum завелся, разработка на проектах.
Вопрос поддержки - два уровня... если первый не справляется то задача прогерам.
Борюсь с офисной мудой - чтоб прогеры меньше отвлекались на вопросы аналитиков и консультанотов (особенно если они вообще не по теме)
asisdes; intrata; spawn8995; blindcat2006; Agrognom; Perk0n; zfilin; +7 Ответить
2. Silenser 519 27.02.15 11:12 Сейчас в теме
Видимо меня заминусуют, но я не вижу реальных плюсов от новой схемы. Трекер + приоритеты решали бы все описанные проблемы на ура, а так удлинили цикл разработки и увеличили время на планирование и сопутствующие вещи, что в итоге выльется в падение производительности людей, которые будут отвлечены от работы занесением дополнительных аналитик в новую систему.
Вопрос саппорта решается выделением времени сотрудников на этот самый саппорт с ведением длинных тикетов, которые имеют шанс перейти на другого сотрудника, в трекере.
Вопрос взаимовлияния разработки решается либо наличием архитектора системы, либо документированием аналитиками.
Так к чему же эта работа ради самой работы?
ПС: это не попытка наехать на автора, скорее вопрос, обусловленный личным негативным опытом, когда внедрением подобной схемы закончилось развалом команды (из 12 работников отдела ИТ 10 покинули компанию, при этом ни одна из заявленных новым РП целей не была выполнена в срок, что было объяснено старыми кадрами, но даже набор новых не дал результатов, все как в анекдоте про 3 конверта)
davydoff; ivv1970; olegmedvedev; +3 Ответить
8. Сурикат 298 17.08.17 13:32 Сейчас в теме
(2)
Если мы говорим о порелизной разработке, то гибкие методологии удобнее, чем приоритеты.
+ при наличии сильно изменяющихся требований они дают определенные плюсы. Мы же выкатываем почти всегда законченную функциональность

И очень сильно зависит от культуры команды. Если люди не понимают какие проблемы такие методологии решают, то они и не зайдут
3. 1Service2 12.05.16 12:08 Сейчас в теме
4. 1c-intelligence 9868 17.08.17 11:53 Сейчас в теме
Расскажите, пожалуйста, насколько возросла скорость разработки в попугаях за время использования скрама?
10. zfilin 2157 18.08.17 14:45 Сейчас в теме
(4) Давно все это было. Скорость "в попугаях" плавала, то росла, то уменьшалась. Сейчас не отвечу на этот вопрос.
Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.

(5) Спасибо. Это стенограмма с выступления.

(6) Вы немного ошибаетесь. "Боитесь" это не то слово. Просто разработка и поддержка это немного разные виды деятельности и не все могут мгновенно вынырнуть из отладчика, ответить на вопрос "почему у меня не проводится реализация", а потом так же быстро погрузиться обратно в отладчик.
Именно с таким дроблением времени и была призвана бороться пожарная машина. Ну, а что описал я это с иронией словами "несчастный" и "обречен", так в любом даже самом серьезном деле есть время "погыгыкать".
14. 1c-intelligence 9868 21.08.17 19:45 Сейчас в теме
(10)
Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.


Два вопроса, если позволите:
1. Управляемость и прогнозируемость процесса разработки вы как-то измеряли? Как определили, что они повысились?
2. Почему вы назвали это "главным"? Оно было главным изначально, как цель? Или стало главным в итоге, как лучший из полученных результатов?

Спасибо.
16. zfilin 2157 30.08.17 14:35 Сейчас в теме
(14)
1. Повышение управляемости стало очень заметно заказчику. Мы не вели "количество положительных отзывов" как исчисляемую метрику, но улучшение было видно "невооруженным взглядом".
После внедрения заказчики (руководители профильных департаментов, например) начали получать достаточно точную информацию о том, в какие сроки будет реализован тот или иной запрашиваемый функционал, против "ну, будет готово когда-нибудь, как будет готово".
Получив доступ к бэклогу и возможность присутствовать (по желанию) на митингах, стали понимать какая фича находится в разработке в данный момент, какая запланирована в эту итерацию, а какая отложена до следующей. Что в конечном итоге привело к пониманию, какие требования и задачи менять уже нельзя, а где еще можно сказать "я передумал, давайте тут поменяем, у вас оно все-равно на следующую итерацию запланированно".
Присутствуя на демо заказчики могли видеть получившийся результат и могли тут же внести в бэклог какие-то новые требования, корректировки на следующую итерацию. А не получали обратную связь уже от конечных пользователей, когда тех уже "достала эта тупая 1С".
То-есть разработка стала более понятной и прозрачной для заказчика и как следствие, заказчик получил возможность этот процесс _разумно_ "направлять" в русло интересов бизнеса, в конце-концов.
17. zfilin 2157 30.08.17 14:37 Сейчас в теме
(14) Про управляемость процесса внутри комманды писать не буду, сам Scrum достаточно хорошо и красиво описывает это. Митинги, ретроспектива, доска - все это иструменты упорядочивающие отношения внутри команды и во многих статьях про это и так уже сказано.
19. zfilin 2157 30.08.17 14:59 Сейчас в теме
(14) 2. Да, это изначально было основной целью. Скорость все-таки была на втором месте.
15. Yashazz 3194 23.08.17 19:28 Сейчас в теме
(10)
Скорость "в попугаях" плавала, то росла, то уменьшалась... Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.

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

Интересно, долго этот сферический в вакууме просуществовал? Долго ли придерживались сиих положений?
1c-intelligence; +1 Ответить
18. zfilin 2157 30.08.17 14:57 Сейчас в теме
(15) Я думаю, что вы противник agile-подходов, что нормально. Agile не серебрянная пуля и не обязан всем нравится.

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

Зубоскалить:
"долго этот сферический в вакууме просуществовал?" - вам же на самом деле не интересно долго или нет.

Додумывать за топикстартера:
"и никак - подчёркиваю, никак - не принесли пользы бизнесу" - это не так, почитайте (16).

Говорить провокационные глупости:
"самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась" - очевидно, что скорость создания никому ненужного функционала никому не принесет пользы. Вопрос не в том "как быстро", а "делаем ли мы то, что нужно".

Демонстрировать полное незнакомство с вопросом, типа "слышал звон":
"ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства" - это все, что вы опровергаете, заложено в 12 принципов agile и метолологии.
Без фрагментации невозможно планирование и нормальное ведение бэклогов. Для контроля есть дэйли-митинги, для прозрачности - демо. И еще много чего. Начните хотя бы с этого - http://agilerussia.ru/category/books/

Боюсь, нам с вами не по-пути.
22. Yashazz 3194 31.08.17 20:24 Сейчас в теме
(18)
вам же на самом деле не интересно долго или нет
Эдак Вы лихо решаете за других, что кому интересно и что кому нет. За своих клиентов так же уверенно решаете?) Если я спросил, значит, интересно. Я статистику провалов веду - ну, если кто вообще признаётся. Обычно это выдыхается и вырождается в пределах года. Что, хватит духу сказать, сколько прожил более-менее полно внедрённый подход? Или увильнёте?

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

"самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась" - очевидно, что скорость создания никому ненужного функционала никому не принесет пользы. Вопрос не в том "как быстро", а "делаем ли мы то, что нужно".
Стоп-стоп-стоп. Вы ж сами сказали, что скорость не выросла. Не путайте тёплое с мягким. Если Вы под "то, что нужно" подразумеваете внутренний самоконтроль группы разработчиков, то это вопрос даже не управления проектом, а чёткости поставленной задачи (ТЗ) и профессионализма исполнителей.

"ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства" - это все, что вы опровергаете, заложено в 12 принципов agile и метолологии.
В теории - может быть. На практике, повторюсь, сперва пафос, а после пшик и проблемы. Я говорю от чистой практики.

А вообще, выбранная Вами тональность и конкретные фразы на грани оскорбления похожи либо на толстый троллинг, либо на классическое оскорблённое величество Господина-Бизнес-Консультанта. Видал я таких, и не раз.

Я тут Вам немножко изобразил реакцию прагматика на всякие заумные изыски, притом, что нужда в решении заявленных вопросов безусловно есть. А Вы грубите. В общем, нашей группе компаний эту методологию в своём изложении Вы, увы, не продали)))
25. zfilin 2157 01.09.17 10:48 Сейчас в теме
(22) Если вам нужны ответы на вопросы, приходите в личку. Расскажу все что знаю. Кстати, у меня к вам тоже есть несколько вопросов.
Но я думаю, что вы скажете что-то типа "а что нельзя ответить мне в комментариях?" и в личке я вас не дождусь, потому что вы тролль и вам не важно получить информацию и новые знания, а важно публично провоцировать участников обсуждения.
5. genayo 17.08.17 12:01 Сейчас в теме
Вот, наконец то статья с нормальными практическими примерами, а не чистая теория...
6. Vovan1975 13 17.08.17 12:40 Сейчас в теме
У несчастного на рабочем месте стояла большая красная машина (та, которая на картинке). И все знали, кто на этой неделе обречен общаться с пользователями и заниматься их сиюминутными проблемами.


вот в этом, ребята, ваша проблема. Вы боитесь общаться с народом.
корум; +1 Ответить
7. Vovan1975 13 17.08.17 12:45 Сейчас в теме
и да, не могу не оставить это здесь:
"SCRUM или шабаш ведьм"
http://blog.jdevelop.com/software/2014/03/25/lifestyle.html
9. 1c-intelligence 9868 18.08.17 08:44 Сейчас в теме
(7)
и да, не могу не оставить это здесь:
"SCRUM или шабаш ведьм"
http://blog.jdevelop.com/software/2014/03/25/lifestyle.html


вы сами что думаете про то, что написано по этой ссылке?
11. zfilin 2157 18.08.17 14:59 Сейчас в теме
(7) Я могу вам еще одну ссылку дать, тоже интересную - https://ebanoe.it/2016/12/26/woxapp-scrum-slavery/

Критика методологии была очень популярна в начале, когда она только приборетала популярность. Более того, была обоснованной, так как были ошибки, неопытные scrum-мастера, scrum тулили где он нужен и не нужен и даже делали все совершенно противоречащее принципам agile, называли это agile и жаловались какая гадость этот scrum.

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

И да, сейчас я не использую гибкие методологии, потому что в конкретно данный момент не вижу это для своей комманды целесообразным. Однако, как только понадобится, я с удовольствием снова ими воспользуюсь.
12. Vovanches 18.08.17 15:47 Сейчас в теме
Люди, откуда у вас столько времени, чтобы заниматься этой фигней?
Yashazz; vitalbasl; +2 Ответить
13. tailer2 18.08.17 15:53 Сейчас в теме
20. Neco 128 31.08.17 14:12 Сейчас в теме
Во всех этих играх с Agile важно, чтобы ваш заказчик знал, понимал и участвовал в процессах планирования и демо. Нужно объяснить сотрудникам заказчика, что задачи выполняются по приоритету, приоритет вот это бэклог и что надо, как-то в него заглядывать а не строчить гневные письма типа когда вы это сделаете.
23. Yashazz 3194 31.08.17 22:14 Сейчас в теме
(20) Заказчик не будет никуда заглядывать. Вы можете предоставить сотни удобнейших бэклогов, равно как и любых иных средств мониторинга процесса. Заказчик, а особенно внутреннее руководство, хочет простых вещей, чтоб всё и побыстрее. И если заказчик вдруг узнаёт, что вместо экстенсивного роста скорости выполнения работ исполнители заняты какой-то малопонятной внутренней интенсификацией с каким-то эйджилом, то единственная реакция, нормальная бизнесовая реакция, такова: "вам что там, делать нехрен?". А сотрудники заказчика будут в меру своей скандальности орать, что всё просрочено, ничего не работает итд.

Как вы не поймёте, что тут вообще главное другое. Что никому, кроме вас самих и вашей группы разрабов, не интересно всё это и бесполезно. Что эмоциональный неадекват истеричных заказчиков, которые в сети ужастиков начитались, визита ФНС испужались, чё-то где-то слышали от знакомых итд, никак не коррелирует с вашей "прозрачностью и управляемостью", и единственное, чем его можно перекрыть - силовой административной поддержкой либо сверхбыстрым выполнением ВСЕХ задач СРАЗУ. И в том, и в другом случае всё вышеопубликованное в лучшем случае страдание фигнёй. В худшем - нецелевая трата времени и сил. Году, помнится. в 2002-м одного такого при мне вышибли с его группой коллег, с треском. Из достаточно крупной телекоммуникационной конторы. Потому как он на вопросы главбуха про какие-то спринты рассказывал, а "у него крыжики и краснота". Будьте реалистами, коллеги.
24. alex_sh2008 4 01.09.17 09:09 Сейчас в теме
(23)
Будьте реалистами, коллеги.

Agile и создали реалисты. Нужно просто правильно применять эти методики в реальной жизни. Насколько я понял сейчас эта фишка среди 1С стала очень популярна, при это люди толком не понимают, а что же это такое на самом деле, вот и вылезают проблемы о которых вы говорите. На самом деле именно Agile и помогает работать с не адекватными заказчиками, главное что бы команда которая для себя выбрала именно эту методику должна точно оценивать риски. Одна команда не сможет одновременно и писать продукт и поддерживать его, проект развалится очень быстро.
21. deminded 7 31.08.17 17:43 Сейчас в теме
Очень похоже на нашу историю, но у нас еще куча нерешенных проблем =) Есть и отличия:
Дежурный у нас меняется ежедневно;
Продукт один, эпиков много и они относятся к разным бизнеса;
Для оценки в "Попугаях" решили ввести список эталонных задач;
Вместо инженерного дня у нас под технологические задачи выделено отдельное количество SP в спринте;
Мы зависли в переходе от оценок Tasks к User Story, но уже понимаем, что надо когда берем в спринт User Story делить ее на кучу Tasks, одна из которых будет документация...
26. Yashazz 3194 01.09.17 15:11 Сейчас в теме
В личку пришёл. Если хотите слегка пооффтопить прямо тут - с 03.09.17 буду к вашим услугам.

потому что вы тролль
Знаете, очень забавно выглядит, когда абсолютно (подчёркиваю, абсолютно) все виденные/читанные мной проповедники подобных систем, будучи предметно спрошены о конкретном выхлопе, впадают в тот или иной неадекват и пытаются прекратить общение.
Я вот вас спрашиваю: что получил бизнес, кроме прозрачности? Вы стали успевать втиснуть критическую задачу между плановыми так, чтобы их сроки не сдвинулись? Вы распределили ресурсы так, что разработчики перестали трудиться сверхурочно при факапах?
28. zfilin 2157 01.09.17 16:34 Сейчас в теме
27. Yashazz 3194 01.09.17 15:21 Сейчас в теме
А самое главное, что никакие обвинения в троллинге не способны опровергнуть зримый и ощутимый опыт. Опыт стабильного провала всех этих эйджил-заумей. Когда руководители проектов и отделов доводили всё до полнейшего трындеца и, извините, мне сотоварищи приходилось своим горбом вытаскивать проекты. Когда приходилось при всей этой красотени лично вправлять мозги заказчикам и терпеть их матюки. Когда отбирали премию именно потому, что мы "вместо работы всякие хрени сами себе внедряем". Когда, наконец, 1С триумфально внедряет Agile и качество платформы, начиная с 8.3.7, падает ниже плинтуса, каждый релизит своё, багтрекер живёт своей жизнью, ранее исправленное всплывает опять, и с подблоками внутри платформы бардак полнейший.
Опыт, он штука такая. Факт есть факт.
29. zfilin 2157 01.09.17 16:34 Сейчас в теме
30. genayo 01.09.17 17:26 Сейчас в теме
(29) Жаль, что в личку. Работа с возражениями - очень интересный навык :)
31. zfilin 2157 01.09.17 21:45 Сейчас в теме
(30) Если в личной переписке станет понятно, что я ошибся и уважаемый Яков Коган не тролль или, возможно, у нас в беседе будут важные мысли в тему публикации, то мы обязательно вернемся в комментарии. До тех пор треду лучше обойтись без наших препирательств.
32. Yashazz 3194 04.09.17 01:12 Сейчас в теме
Заметьте, я высказался по публикации, а автор - по моей персоне. Разницу ощущаете?)
33. alex_sh2008 4 14.09.17 09:29 Сейчас в теме
(32)Ну и чем все закончилось, мировая или ошибки ни кто не хочет признавать?
34. Yashazz 3194 17.09.17 13:49 Сейчас в теме
(33) Довольно конструктивно пообщались в личке, пришли к выводу, что "стороны опубликуют совместное коммюнике", на этом всё и зависло. Работа не волк, работа "ворк". И я замотался, и Александр, видимо, тоже.
36. zfilin 2157 20.09.17 15:12 Сейчас в теме
(33) (34) Так и есть. Насыпало работы и разъездов.
При первой же возможности итоги опубликуем.
Оставьте свое сообщение

См. также

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

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

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

04.04.2019    11350    67    infostart    18    

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

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

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

18.05.2020    7493    0    MariaTemchina    31    

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

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

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

23.03.2020    3937    0    MariaTemchina    23    

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

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

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

03.03.2020    4692    0    VLikhobabin    44    

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

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

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

24.01.2019    8784    0    user809424    11    

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

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

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

23.01.2020    8528    0    MariaTemchina    8    

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

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

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

09.01.2020    5077    0    roman72    0    

Про одну Тётю

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

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

24.12.2019    5653    0    1c-intelligence    32    

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

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

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

29.06.2017    32523    0    1СERP    79    

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

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

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

14.10.2019    5035    0    chavalah    16    

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

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

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

19.09.2019    10843    0    ogroup    161    

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

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

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

16.09.2019    8221    0    GSoft    15    

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

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

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

09.06.2017    29557    0    1СERP    175    

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

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

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

30.08.2019    9601    0    SergeyN    5    

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

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

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

20.08.2019    7266    0    KoldunOne    7    

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

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

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

16.08.2019    7103    0    Hissin    18    

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

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

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

18.04.2017    30414    0    1СERP    189    

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

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

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

28.06.2019    6690    0    SergeyN    1    

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

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

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

24.06.2019    5713    0    sbase    9    

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

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

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

19.06.2019    8733    0    FB_10160810658600104    62    

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

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

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

10.04.2017    30233    0    1СERP    107    

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

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

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

18.06.2019    6510    0    MariaTemchina    8    

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

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

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

31.05.2019    7493    0    MariaTemchina    23    

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

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

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

14.05.2019    10217    0    1c-intelligence    120    

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

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

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

03.04.2017    40802    0    1СERP    231    

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

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

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

06.05.2019    6526    0    MariaTemchina    8    

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

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

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

04.05.2019    7914    0    1c-intelligence    39    

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

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

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

15.04.2019    10239    0    MariaTemchina    15    

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

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

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

23.02.2017    26335    0    Gavrik    9    

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

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

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

13.02.2019    7356    0    chavalah    22    

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

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

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

12.02.2019    8835    0    MariaTemchina    20    

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

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

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

04.02.2019    8823    0    1c-intelligence    64    

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

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

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

17.06.2016    38851    0    raiml    37    

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

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

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

31.01.2019    7425    0    MariaTemchina    0    

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

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

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

14.01.2019    9157    0    MariaTemchina    13    

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

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

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

10.01.2019    11534    0    chavalah    123    

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

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

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

26.12.2014    43230    0    CheBurator    64    

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

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

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

26.12.2018    8760    0    1c-intelligence    7    

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

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

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

19.12.2018    8768    0    MariaTemchina    24    

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

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

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

09.12.2018    8142    0    chavalah    119    

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

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

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

1 стартмани

14.09.2015    35192    0    axxell    15    

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

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

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

05.12.2018    16055    0    andironenko    128    

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

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

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

03.12.2018    7696    0    capitan    26    

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

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

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

26.11.2018    8842    0    MariaTemchina    40    

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

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

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

06.04.2015    36882    0    raiml    14    

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

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

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

23.11.2018    10202    0    Selikhovkin    8    

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

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

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

22.11.2018    11544    0    andironenko    43    

Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8

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

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

19.11.2018    7066    0    Selikhovkin    1    

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

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

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

16.11.2014    28029    0    raiml    46    

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия)

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

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

19.11.2018    8535    0    capitan    41    

Почему внедрение ERP-системы не приносит пользы бизнесу?

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

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

15.11.2018    21041    0    rossoxa    63    

Думать некогда, трясти надо - или что такое ретроспектива в Agile

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

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    9329    0    MariaTemchina    16    

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

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

Продолжаю цикл материалов, в котором рассказываю о своем опыте работы в качестве директора по ИТ. Этот материал будет посвящен теме управления персоналом.

07.11.2018    11388    0    andironenko    62