Применение Agile-технологий в проектах 1С

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

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

Agile – это одна из методик ведения проектов. О ее практическом применении в проектах 1С пойдет речь в статье.

Что такое Agile?

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

 

 

Что такое спринт? Это некий отрезок времени, за который надо получить определённый результат. Мы можем не получить всю систему в целом, но определенный результат  должны показать. Причем это результат, который принимает заказчик.

 

Особенности заключения контрактов типа Agile

Отличительный момент проектов Agile – отсутствие перспектив на постановку технического задания и получения в целом какого-то решения. Здесь нет такого, что сначала мы пишем полгода техническое задание, потом 2 года программируем, а потом показываем заказчику продукт. Все сводится к тому, что мы определяем общие с заказчиком цели, которые хотим достигнуть. В договоры наша компания даже добавляет такой раздел, как «Цели», и прежде чем идти в проект, мы их прописываем.

Важно понимать, что цели из разряда «получить новую платформу» или «автоматизировать» – это не цели. Цели должны быть сформулированы конкретно. Например, получение структуры себестоимости или отчета по себестоимости с визуальным представлением. Это цель. Заказчик понимает, что когда он увидит такую-то формочку, пусть она даже в экселе нарисована, это достижение цели, это то, что нужно принимать. Какая-то обработка – это тоже может быть целью. Поэтому цели должны быть четко расставлены и должны быть визуальными/ощутимыми.

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

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

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

 

 

Проектирование по Agile

В этой системе нет такого этапа, как постановка технического задания. Мы против этого этапа, потому что фактически онзаканчивается тонной макулатуры, которая потом мало применяется. Чаще всего с постановкой ТЗ приходится сталкиваться при работе по госконтрактам, когда техническое задание необходимо и является неотъемлемой частью.

Тем не менее, этап проектирования в Agile есть, от него никуда не уйти. Он представляет собой следующее: в 1С проектах на 99% всегда решение строится на базе другого готового решения. Если управленческий учет – это ERP или управление торговлей, есть много отраслевых решений. Это понятно на этапе предварительных переговоров с заказчиком. Наш проект строится на уже готовых решениях. На предпроектных работах мы берем готовую систему и наполняем ее рабочими данными – это входит в состав предпроектных работ. Если мы переходим с существующей системы, мы заранее будем готовить конвертацию, и будем заполнять сразу реальными данными. И все проектирование сводится не к получению какого-то документа, а к построению системы и ее запуску.

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

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

 

Оценка работы

Спроектированный состав работ имеет вид задач, списка. Встает вопрос, как все это оценить. Методик оценки много, они разные и интересные. Где-то сидит эксперт, который говорит, сколько часов это займет, умножает их на стоимость нормо-часа. В другом месте сидит менеджер, который понимает, сколько можно «скормить» заказчику. В третьем придуман еще какой-то способ.

В нашей компании пользуются технологией, которая называется Agile Planning Poker. Ее, кстати, можно использовать в самых разных ситуациях, она применима не только для оценки, и не только в Agile.

 

 

Как работает эта технология? У каждого программиста, у каждого участника команды есть такая колода карт с цифрами. Рассчитываем, сколько часов именно на разработку необходимо потратить. Программисты берут карты рубашкой вверх и потом вскрывают их. Если количество часов не будет отличаться больше чем на 10-20 процентов, берётся максимальная оценка. Если один дал 2 часа, а другой – 10 часов, это значит, что оценка сильно отличается. Тогда начинается обсуждение, потому что вполне вероятно, что прав тот человек, который дал большую оценку, поскольку он понимает, что потребуется больше времени. Может быть и наоборот: тот, кто дал больше часов, чего-то не понимает, потому что уже где-то есть готовое решение, которое можно скачать и все быстро сделать. После обсуждения идет переоценка.

То есть мы получаем некий корсет прямых затратпрограммистов. Еще одно преимущество этой технологии в том, что команда сама дала оценку. Если оценили в 10 часов, а потратили 200 часов, обвинить какого-то одного человека будет очень сложно. Ребята вместе оценивали и смотрели на задачу.

 

Составление сметы

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

 

 

 

Формирование плана-графика

Планировать в Agile на длительный период никакого смысла нет.

 

 

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

Второй план более детальный, мелкий. Он называется спринты.

 

 

Спринт содержит в себе определённый состав задач на 1-2 недели, максимум на 4 недели. Спринт менять нежелательно, это список задач, которые фиксируются, и изменять их неправильно. У нас, например, к спринтам привязана система мотивации, и команда прекрасно понимает, что все поставленные задачи надо выполнить за короткий промежуток времени.

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

 

Собираем хорошую команду

Проектная команда формируется для решения разных задач, и должна состоять обязательно из четырех частей. Притом обязательная часть представлена на картинке с левой части, а необязательная – справа. Разберемся, кто есть кто.

 

 

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

Еще одна обязательная фигура – ведущий программист или, как его еще называют, архитектор. Это специалист проектной команды. Специфика Agile проектов в том, что команда исполнителя должна быть в очень тесном контакте с заказчиком. Любой продукт, который делается по технологии Agile, должен делаться совместно с заказчиком. Тестирование интерфейса, разработка – все совместно с ним. Идеальный Agile продукт – когда исполнитель сидит на территории заказчика.

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

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

 

Как происходит закрытие спринта?

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

 

 

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

Цели митинга:

  • разобрать новые задачи;
  • распределить, кто и что делает;
  • разобраться с зависшими стикерами, которые остались в процессе.

Идеальное время проведения митинга – не более 10-15 минут. Если митинг затягивается, что-то идет не так. Если полчаса или час – это уже нелепое совещание по непонятному вопросу. Если появилась какая-то проблема, которая требует обсуждения на проекте, например, техническая сложность, тогда надо отдельно садиться и обсуждать.

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

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

 

Как сдается спринт?

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

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

Как же мы сдаем работы? Кто является ключевыми фигурами?

Мы выделяем три ключевые роли со стороны заказчика:

 

 

  1. Лицо, которое будет эксплуатировать, конечный пользователь или его руководитель. Контакт с этими людьми должен быть постоянным.
  2. Лицо, которое отвечает за приемку работ. Когда вы беретесь за какую-то часть работы, важно понимать, как и кем она будет приниматься. С этим лицом надо контактировать хотя бы раз в 1-2 недели, потому что спринт надо сдавать ему, этот человек будет подписывать акт о выполнении этапа работ.
  3. Лицо, которое платит. Это может быть инвестор, акционер, человек, деньги которого непосредственно тратятся. Он может быть далек от проекта, но очень важно с ним поддерживать связь, пусть даже кофе попить. Ведь когда он платит, ему важно понимать, за что он платит. И на этом этапе всегда важно поддержать контакт. Зашли раз в полмесяца/месяц, рассказали, как идут дела на проекте. Обязательно надо сделать акцент на результат, что получили – подсистему, документ. Быстро и коротко. Чтобы человек знал, куда идут его деньги.

 

Учет рабочего времени

Поскольку мы говорим про 1С, а это сфера, где работают программисты и консультанты, нашим продуктом является наше время. Есть то время, которое мы получили при планировании задач, – это так называемое инвойсное время, инвойсные часы. И есть то, которое фактически потрачено.

 

 

Бывает, что оценили задачу в 10 часов, а потратили на нее 200 часов. Очень важно разобраться, почему это произошло: мы недооценили или эффективность сотрудников слишком низкая. Тайм-менеджмент в нашей компании сводится с детализацией отчетов до 15 минут. Мы заполняем ежедневно отчеты и понимаем, чем занимался человек. Кроме того, у нас есть отчеты по эффективности, которые позволяют оценить и каждый проект, и каждого сотрудника.

 

Мотивация в проектах Agile

Существует множество способов мотивации. Но программисты – не продавцы, мотивировать полной сдельщиной их не получается. У них мотивация внутри, они должны понимать, зачем что-то делают. Кроме того, если им интересно – они делают, неинтересно – не делают.

 

 

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

Что такое план – это количество часов, закрываемых за календарный месяц по проектам или оценкам. Этот план зависит от количества рабочих часов в месяце и градации специалиста. Например, специалист 4 категории из 180 часов должен отработать 80 или 40 часов, а программист первой категории – например, 120.

Исходя из планов и отчетов сотрудников, мы можем посчитатьфактически отработанное время. Есть непосредственно окладная часть – она привязана к категории и составляет примерно 60% дохода. Остальная часть строится, исходя из закрытых часов. Если сотрудник выполняет план или перевыполняет, он получает премиальную часть. Таким образом, вся команда замотивирована и работает не только на процесс, но и на закрытие максимального количества задач за адекватное время.

В нашей компании еще есть схема мотивации, завязанная на своевременное закрытие спринтов. Таким образом, мы закрыли 2 проблемы: 1 – работоспособность и эффективность людей, которые понимают, на что они работают, а 2 – соблюдение сроков, которые очень часто срываются.

 

Гарантийные работы

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

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

 

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

 

Достоинства и недостатки технологии Agile

Достоинства:

  • Минимальный риск за счет поэтапной приемки.

 

Цена риска – всегда один спринт. Когда мы делаем по какому-то договору большой проект по ТЗ, мы понимаем, что если вдруг не сдадим работы, что-то поменяется, заказчик обанкротится, появится новый руководитель, нам деньги не заплатят, и проект завалится. В нашем случае всегда цена риска – один спринт. Мы можем его оценить в денежном эквиваленте. Например, если наш риск 200 тысяч рублей, то мы точно знаем, что больше мы не потеряем. Многие компании любят брать аванс – 50% и дальше работать, делать проект, а по его окончании – получают вторую часть. Но если будут какие-то перемены, то они потеряют именно 50%. У нас риск минимизирован. Главное понимать конкретную сумму, и быть готовым к такой потере.

 

  • Прозрачный результат для всех сторон.

 

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

 

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

 

  • Минимальные сроки.

 

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

 

  • Нацеленность команды на результат.

 

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

Недостатки:

  • Отсутствие бюджета на полный проект.

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

 

  • Расход времени на проведение митингов.

 

Митинги, которые проводятся ежедневно, собирают всю команду. Даже если брать митинг длительностью 15 минут плюс кофе-брэйк, все равно команда тратит время. Иногда неэффективно. Трата времени есть, если например, сидим, объясняем задачу для одного человека, а слушают еще 4. Но в то же время это является плюсом, потому что члены команды взаимозаменяемы.

 

Резюме

Очень важно помнить: в Agile мы работаем на результат, а не на процесс. Результат виден с первых ступеней, и вся работа исполнителя завязана на то, чтобы как можно плотнее сотрудничать с заказчиком и быстро получить результат.

 

***************

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

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. grumagargler 679 25.07.17 23:44 Сейчас в теме
Четко изложено, спасибо. Наверное выскажу непопулярное мнение, но всегда остается устойчивое ощущение, что подавляющее большинство тех, кто занимается внедрениями на платформе 1С с какими-либо доработками, уже последние лет 20+ именно по аджайлу и работают, еще со времен когда Казачков желтые книжки только начинал писать. Есть ТЗ или нет, дело вкуса можно сказать, но внедрять 1С без тесного взаимодействия с заказчиком, писать что-то год, а потом ставить ну не такая уж частая практика. Работа на месте у заказчика – так это вообще привилегия 1С-программистов, во всяком случае, до относительно недавнего времени, когда внедренец-программист еще был устойчивым образом. Другими словами, аджайл это здорово, но ведь мы вроде этим и так уже очень давно занимаемся…
TreeDogNight; корум; Spartacus; Yakud3a; kuntashov; itriot11; Bobak; zGainer; danik05ru@mail.ru; smit1c; dabu-dabu; 9-pm; gzharkoj; +13 Ответить
5. nixel 1000 26.07.17 10:19 Сейчас в теме
(1) не путайте, пожалуйста, нормальный аджайл с практиками программирования и тот ужас, что происходит в мире 1с)
Yasen; neikist; d4rkmesa; SelikhovVV; +4 Ответить
12. d4rkmesa 26.07.17 19:56 Сейчас в теме
(5) Это точно, какие там спринты по 2-3 недели, ну разве что в проектной команде на ERP. По большей части часто все происходит "на коленке", задачи в лучшем случае фиксируются в редмайне или каком-то аналоге канбан-доски. Переиначивая поговорку, "каков приход таков и поп".
7. nk25 26.07.17 13:00 Сейчас в теме
(1)
на платформе 1С с какими-либо доработками, уже последние лет 20+ именно по аджайлу и работают
- как сейчас помню конец 90-х крупный банк, большая система , внедрение с доработками, оплата по этапам, команда от заказчика , команда от разработчика и далее по тексту . Но это была не 1с , а Agile-scrum и прочих слов не использовали.

Первый раз попалась заметка без упора на канбан, скрамбан , берндаун, фикси,спринт,фича . И это радует.
2. diso 265 26.07.17 07:19 Сейчас в теме
По-моему это организация запрещенная в России ))))
корум; SerLeon; RSConsulting; Sheff; Yakud3a; +5 Ответить
3. Stepa86 1410 26.07.17 07:58 Сейчас в теме
Agile это методология, он говорит лишь о приоритетах в разработке, но совершенно не говорит про то, как работать и что делать.

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

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

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

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

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

А то, что у вас есть отличия от классики - чуть чуть другое распределение ролей, добавление мотивации, сдача работ и прочее - это прекрасно, это значит, что вы адаптировали процесс под себя, а не тупо внедрили то, что прочитали в книжке и используете, не понимая зачем это все.
Vladimir Litvinenko; Ta_Da; TreeDogNight; корум; Lemoi; ivanov660; neikist; sanjabor; newdigger; kolya_tlt; MGraf; dabu-dabu; +12 Ответить
4. rovenko.n 26.07.17 09:40 Сейчас в теме
Хорошая статья. Единственный момент - "ТЗ - это тонны макулатуры" - этот момент очень часто становится камнем преткновения с Заказчиком.
Расскажу на примере:
Перед запуском проекта было четко указано - мы собираем требования с пользователей, потому что они потом будут пользоваться системой. Заказчик кивнул, но на этот момент внимания не обратил. В результате при демонстрации реализованного функционала всё было отлично по пунктам по Эджайлу, но при реализации всей разработки оказалось, что сбор требований производился не с тех людей. А у нас есть ТЗ, на котором стоит подпись Заказчика. Потому ответственность не наша.
TreeDogNight; +1 Ответить
6. DonAlPatino 152 26.07.17 10:38 Сейчас в теме
Хорошо, что тут не хабр. Съели бы за незнание терминологии. Хоть бы wikipedia посмотрели прежде чем презентацию делать и на infostart с ней выступать. Тема старая и разжеванная. При том что действительно мир 1С многие элементы agile давно использует, только об этом не знает :-)
То что вы написали - это Scrum. НО за "scrum master = руководитель проекта" agile специалисты убивают медленной и мучительной смертью, т.к. она всю идею скрама отправляет в утиль.
Что бы не повторяться - на хабре много правильных и полезных статей по этой теме. Лучше читать там... А то выглядит как "наш бардак мы назовем красивым словом agile и пойдем с этим по жизни".
Vladimir Litvinenko; Yasen; Lemoi; neikist; Циник; SelikhovVV; +6 Ответить
8. starik-2005 2266 26.07.17 13:18 Сейчас в теме
9. Dzenn 462 26.07.17 15:46 Сейчас в теме
Тошниловка ваши аджайлы. Обычный здравый смысл под заморским словом.
DarkUser; BabySG; rovenko.n; Ta_Da; корум; Yashazz; +6 1 Ответить
10. Darklight 27 26.07.17 17:42 Сейчас в теме
Пожалуй главные недостатки методологии, с точки зрения заказчика, в её сути:
1. Нет общего бюджета - заказчик не знает во в сколько ему это всё обойдётся и сколько денег ему нужно готовить в единицу отчётного времени. Это очень сильно напрягает большинство заказчиков. Конечно кое-какие оперативное планирование затрат умелые финансисты организовать смогут, и даже можно сделать прогнозную оценку для составления стратегического годового или многолетнего бюджета. Но всё это лишь создаст проекту сильные ограничивающие рамки, которые будут его тормозить и снижать эффективность.
2. Сдача блоков мелкими частями хороша лишь когда система потихоньку дорабатывается и развивается. А когда заказчику нужен переход от одной системы к другой (что чаще всего и происходит), то такой подход уже не годится - заказчик попросту не сможет работать в системе, решённой на 1%, 5%, 30%, даже в системе решённой на 60-80-90% от имевшегося старого функционала эффективно работать (даже по сравнение с тем "убожеством", что было заказчика ранее, практически нереально. Это так же будет очень сильно напрягать заказчика и фактически сведёт сдачу частей проекта как "сферической лошадей в вакууме" : да увидели как оно должно быть, да пощупали на тестовых данных, но эксплуатировать не можем - т.к. есть много зависимостей с другими блоками и, главное, много нереализованного функционала (даже не входящего сданные спринты), без которого вообще эксплуатировать систему нельзя.
BabySG; Ta_Da; корум; sansys; cesar; miavolas; +6 Ответить
11. Bassgood 1099 26.07.17 19:00 Сейчас в теме
(10) Судь идеи заключается не в сдаче частей функционала системы именно в эксплуатацию, а по крайней мере в их демонстрации заказчику, что эти части проекта уже готовы и могут работать как автономные блоки (пускай и не полностью), которые далее уже будут связываться в единую систему, это дает возможность услышать от заказчика его оценку хотя бы той части проекта, которая уже реализована, и принять на ее основании корректирующие действия, при этом устанив все недочеты в этом блоке еще до начала работ со следующими блоками системы, которые завязаны на него.
Во всяком случае, это лучше чем узнать мнение заказчика о реализованном функционале только по окончанию работ над всеми блоками программы.
newdigger; +1 Ответить
14. Darklight 27 27.07.17 10:29 Сейчас в теме
(11) Для этого испокон веков существуют пилотные решения, а так же черновые наброски макетов рабочих форм, agile и спринты здесь не причём!
16. Bassgood 1099 27.07.17 10:49 Сейчас в теме
(14) И как вы будете демонстрировать заказчику работу этого чернового макета? То что есть макеты рабочих форм это хорошо, но это только цель, которую требуется достичь, заказчик не может их "пощупать" на "живых" данных, для этого и предлагается последовательная реализация этих макетов друг за другом (на каждом спринте по n-макетов) и демонстрация их заказчику, чтобы он мог видеть результаты работы команды "вживую", а не только на бумаге (не только после реализации всех макетов).
13. starik-2005 2266 27.07.17 10:27 Сейчас в теме
(10)
Пожалуй главные недостатки методологии, с точки зрения заказчика, в её сути:
Пожалуй кто-то ничего не знает про CMM и CMMi. Если компания находится на уровне развития 1, то Agile скорее навредит, чем поможет. А если на уровне 5, то без Agiled в принципе туда даже подняться невозможно.

Пока в обычном планировании как происходит? Берется некоторая оценка, умножается на некоторое число ("три", например). Потом руководители проектов начинают неистовую борьбу за ресурсы (программистов, кодеров, консультантов, аналитиков, ...), потом им удается добиться маржинальности, сэкономив ресурсы, ибо оценку предельно завысили. И иногда эти товарищи даже ISO имеют внутри в виде стандарта, как некоего сферического в вакууме коня.
15. Darklight 27 27.07.17 10:34 Сейчас в теме
(13) И много ли компаний в России (из числа не пришедших с запада или востока) вышли за пределы хотя бы 2-го уровня развития (про остальной мир судить не буду). Для большинства Российский реалий Agile больше провален, чем является спасительной соломенкой. Менталитет не правильный.
17. starik-2005 2266 27.07.17 11:36 Сейчас в теме
(15)
Для большинства Российский реалий Agile больше провален
Вы не ту проблему видите. Вот у меня был реальный опыт, когда я с руководителем отдела внедрили Jira и начали работать со спринтами. Реально производительность труда повысилась только от того, что не нужно было метаться между задачами - распланировали на неделю и отвлекаемся только на "аварии". Но у нас уже был внедрен стандарт ISO 9К + инцедентный подход (ITIL 2) по всей конторе целиком.

А проблема тут в другом - нет желания развиваться. Отчасти тут виновато отсутствие конкуренции в ИТ-разработке, ибо желающих получить ИТ-продукт больше, чем тех, кто его производит/внедряет/поддерживает. Ну и лень - куда без нее? Поэтому тот, кто сейчас возмущается различными новыми походами, будет оставаться на достигнутом уровне своей эффективности, медленно деградируя из-за возрастных изменений организма.
18. Darklight 27 27.07.17 12:24 Сейчас в теме
(17) Я, не возмущаюсь. Я говорю, что внедрять эти новые подходы очень тяжело в российскиз реалиях. И больше всего успех их внедрения и применения зависит не от того, насколько ими проникнется ИТ структура, а на сколько ими проникнется бизнес заказчиков.
19. cesar 12 27.07.17 12:56 Сейчас в теме
(17) У вас был проект создания и внедрения новой системы c понедельным планированием задач в JIRA или развитие и сопровождение существующих систем? Эти процессы имеют отличия.
20. starik-2005 2266 27.07.17 14:56 Сейчас в теме
(19)
У вас был проект создания и внедрения новой системы c понедельным планированием задач в JIRA или развитие и сопровождение существующих систем?
У нас было два уровня: инциденты в Itilium и спринты в Jira. был человек, который раскидывал инциденты, часть из них становилась задачами в Jira, а часть отправлялась на HD. Дальше относительно ресурсов либо происходило вытеснение из спринта имеющихся задач новыми (более приоритетными), либо новые задачи оставались в пуле задач, дожидаясь следующего спринта. Таким образом достигалась и прозрачность, и контроль. Сюда же можно было засунуть мотивацию за закрытие спринта в полном объеме.

Если кто-то думает, что он сможет внедрить Agile для поддержки и развития функционала продукта без работы с инцидентами - он глубоко ошибается. А инциденты - это и то, из чего впоследствии может появиться задача. В итоге если просто взять методологию с длинным спринтом и не предусмотреть процесс вытеснения задач более приоритетными, то эффективность такого внедрения будет низкой (если вообще будет). Поэтому или короткие спринты, или длинные, но с профицитом ресурсов команды в 20% для закрытия критических инцидентов.
24. cesar 12 27.07.17 19:13 Сейчас в теме
(20) А инциденты в Итиле и спринты в Jira были по задачам проекта создания и внедрения новой системы или это было доработка и сопровождение существующих систем? Были ли признаки проектной деятельности или это была поддержка?
25. starik-2005 2266 27.07.17 20:55 Сейчас в теме
(24) Это была как поддержка, так и создание нового совершенно функционала. Попытки использования MS Project и прочее были, но дальше сферической диаграммы Ганта дело не шло. Попытки ARIS тоже ни к чему не привели, т.к. просто никто не стал с этим разбираться. А вот Jira и спринты получилось достаточно быстро воткнуть в процессы и разработки, и поддержки.
21. Yashazz 3638 27.07.17 16:44 Сейчас в теме
Когда в самой 1С внедрили эту, простихосспади. хрень, качество продукта резко пошло вниз. Качество всего: и поддержки имеющихся компонент платформы, и создания новых, и их взаимодействия, и документирования, и исправления ошибок. Практика - критерий истины)
23. Bassgood 1099 27.07.17 18:17 Сейчас в теме
(21) Вы уверены, что это связано именно с этим? Как долго это продлилось, они больше не используют ее?
Откуда у Вас такая информация, поделитесь, если не сложно?
27. Yashazz 3638 28.07.17 09:46 Сейчас в теме
(23) Имена называть не буду, просто судьба свела с человеком, работавшим там и видевшим всё непосредственно. Говорю с его слов. Текущее положение дел уже не знаю, но, судя количеству косяков в новых релизах, существенно лучше не стало.
29. alex_sh2008 4 28.07.17 09:57 Сейчас в теме
(27)А причем здесь методики Agile?
33. Yashazz 3638 28.07.17 19:35 Сейчас в теме
(29) а притом, что "вся эта фигня" резко усилилась после внедрения Agile в 1С. Я не делаю прямой логической связи между этими фактами, а равно и допускаю, что внедрение пошло не совсем штатно, но...

(30) а я тоже нажимал. А вот вишь, не было этого. Прямо волшебный Undo случился.

Ладно, не будем особо оффтопить. Мне вот интересно, есть ли хоть один случай внедрения именно так, как завещали отцы-основатели оного, и знает ли кто-то вообще, "что имел в виду автор"?
34. alex_sh2008 4 28.07.17 21:53 Сейчас в теме
(33)
а притом, что "вся эта фигня" резко усилилась после внедрения Agile в 1С

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

как завещали отцы-основатели оного, и знает ли кто-то вообще, "что имел в виду автор"?

Ну вообще то прародитель этих методик вышел из СССР в частности ЦК КПСС, назывались они не Agile конечно, но основа была взята от туда и модернизована для управления циклом разработки программного обеспечения, для взаимодействия множества команд.
26. starik-2005 2266 27.07.17 20:56 Сейчас в теме
(21)
Когда в самой 1С внедрили эту, простихосспади. хрень, качество продукта резко пошло вниз.
А когда это. прастихоспади, оно вообще было вверху? Сейчас 8.3 очень даже неплохо работает. Что не так?
28. Yashazz 3638 28.07.17 09:50 Сейчас в теме
(26) 8.2.19 вполне себе стабильно работает. А вот с 8.3.Х вообще не угадаешь. Пишу это я давеча код в 8.3, сохраняю, а он мне нечто вроде "При редактировании модуля произошла ошибка" - переоткрываю модуль - бац, работу последнего получаса как корова языком слизнула. Это вообще как называется? Это называется "Agile, при котором каждая рабочая группа спешит зарелизить свой кусок, а дальше трава не расти".
rovenko.n; +1 Ответить
30. Bassgood 1099 28.07.17 10:45 Сейчас в теме
(28)
бац, работу последнего получаса как корова языком слизнула

Я жму Ctrl+S каждые 10 мин своей работы ;)
На самом деле 8.3 развивается намного динамичнее, чем 8.2, со своей стороны каких-либо критических проблем в работе с 8.3 не замечал
31. neikist 28.07.17 11:06 Сейчас в теме
(30)Полностью согласен. Платформа и так медленно развивается, в 8.3 хоть немного ускорились и возможности добавлять новые стали. Хоть не на 20 лет от мейнстрима отставать будут возможно.
starik-2005; +1 1 Ответить
32. starik-2005 2266 28.07.17 11:35 Сейчас в теме
(28)
- бац,
У меня такое и на 7.7 было, и на 8.0/1/2/3... Сейчас вот интересная ошибка иногда наблюдается про рассинхронизацию контекста формы на севере и клиенте с какими-то циферками. Ошибок в 1С много - с этим я, лично, не спорю. Но сейчас эти ошибки являются следствием достаточно динамичного развития платформы, которого со времен появления управляемого интерфейса не было: такси (можно по-разному о нем говорить, но мне, лично, нравится), REST/HTTP-сервисы, работа с бинарными данными, мобильная платформа, потоки в памяти - все это нельзя реализовать "бесплатно", за все это платится стабильностью работы решения в целом. Про 8.4 что-то давно не слышно, но там тоже интересные моменты в плане модульности и собственного веб-сервера.

Agile дал, на мой взгляд, достаточно быстрое внедрение интересных кусков кода в платформу (что-то у них даже раньше срока вышло, хотя, обычно, 1С всегда отставала от планов).

А вот по поводу сбоев (что-то при сохранении улетело в никуда), то такое на моей практике и на Borland Pascal 7.0 бывало (и даже на 5.0), не говоря уже о бейсиках на УКНЦ (Электроника МС 0511).
22. gubanoff 50 27.07.17 17:25 Сейчас в теме
35. Teratsov 19 02.08.17 12:20 Сейчас в теме
Так и не понял, о чем вы договариваетесь с Заказчиком на входе в проект и что пишете в договоре. А это интересно. То, что написано в разделе "Особенности заключения контрактов" - идеализация, редкий клиент согласится на проект без бюджета.

Мы у себя делаем так:

1. С клиентом подписывается стандартный проектный договор с плановым бюджетом, единственное отличие - в плане работ работы нарезаются таким образом, чтобы клиент раз в 1-2 месяца получал законченный функционал, решающий проблему клиента. На каждый такой ЭТАП, который заканчивается передачей законченного функционала, с клиентом подписывается допник с фиксированным бюджетом.

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

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

В итоге:
- планируем перед каждой итерацией;
- ретроспективы через одну, после завершения всего описанного в ДС функционала (когда команда свежая, ретро после каждой итерации);
- чекаемся раз в неделю внутренними демонстрациями;
- с клиентом фикс, команда работает по SCRUM;
- клиент получает готовые решения раз в 1-2 месяца, может внести корректировки в требования после первой итерации;
- мы имеем возможность пересогласовывать бюджет следующего ДС, если на предыдущем сработали какие-то риски. Риски в договоре, естественно.
gortol; shootnik; Yasen; A_Max; +4 Ответить
Оставьте свое сообщение

См. также

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

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

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

16.09.2019    10506    GSoft    16    

9 советов, как уговорить девушку. Точнее, как уговорить Заказчика работать по Agile, когда он этого не хочет

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

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

16.02.2021    2551    MariaTemchina    39    

Как умирают розовые единороги, или бизнес-автоматизация как способ сделать людей несчастными

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

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

10.02.2021    3346    andironenko    12    

Статья Компетенции РП по версии PMI и здравому смыслу. Часть 2-ая

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

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

09.12.2020    1525    MariaTemchina    3    

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

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

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

24.01.2019    10174    user809424    11    

Что почитать про Agile для чайников?

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

Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом - вот, я, мол, совсем не представляю, что такое Agile…

03.12.2020    3040    MariaTemchina    9    

Компетенции руководителя проекта: по версии PMI и здравому смыслу. Часть 1-ая.

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

Об компетенции руководителя проекта сломано немало копий (хорошо, если не об самих руководителей).  В этой статье хочу оставить свои пять копеек, отталкиваясь от тех компетенций, которые институт PMI® - законодатель моды мирового проектного управления - озвучил в качестве требований к сертификации PMP® со 2-ого января 2021 года.

18.11.2020    2934    MariaTemchina    8    

Как стать исполнителем в проекте от Инфостарта

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

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    3090    alexandr.blinov    17    

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

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

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

29.06.2017    35241    1СERP    79    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

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

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    3351    MariaTemchina    23    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

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

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

20.08.2020    3128    MariaTemchina    4    

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

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

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

26.06.2020    4624    1c-intelligence    17    

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

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

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

09.06.2017    31584    1СERP    175    

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

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

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

08.06.2020    5312    stepan96    12    

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

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

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

25.05.2020    5804    sapervodichka    1    

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

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

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

18.05.2020    11542    MariaTemchina    33    

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

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

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

18.04.2017    32595    1СERP    189    

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

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

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

23.03.2020    6284    MariaTemchina    24    

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

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

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

03.03.2020    6850    VLikhobabin    44    

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

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

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

23.01.2020    20530    MariaTemchina    8    

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

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

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

10.04.2017    32645    1СERP    107    

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

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

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

09.01.2020    8647    roman72    0    

Про одну Тётю

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

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

24.12.2019    6913    1c-intelligence    33    

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

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

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

14.10.2019    6079    chavalah    16    

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

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

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

03.04.2017    43770    1СERP    231    

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

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

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

19.09.2019    12893    ogroup    164    

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

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

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

30.08.2019    13773    SergeyN    10    

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

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

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

20.08.2019    9358    Arsen1986    7    

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

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

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

23.02.2017    27990    Gavrik    10    

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

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

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

28.06.2019    8607    SergeyN    1    

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

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

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

24.06.2019    6988    sbase    9    

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

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

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

19.06.2019    10560    FB_10160810658600104    62    

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

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

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

17.06.2016    40584    raiml    37    

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

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

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

18.06.2019    7923    MariaTemchina    8    

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

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

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

31.05.2019    10266    MariaTemchina    23    

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

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

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

14.05.2019    11531    1c-intelligence    121    

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

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

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

26.12.2014    45186    CheBurator    64    

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

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

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

06.05.2019    8073    MariaTemchina    8    

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

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

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

04.05.2019    9125    1c-intelligence    39    

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

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

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

15.04.2019    12468    MariaTemchina    15    

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

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

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

1 стартмани

14.09.2015    36542    axxell    15    

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

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

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

13.02.2019    8393    chavalah    22    

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

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

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

12.02.2019    10680    MariaTemchina    20    

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

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

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

04.02.2019    10361    1c-intelligence    64    

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

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

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

06.04.2015    38043    raiml    14    

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

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

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

31.01.2019    8464    MariaTemchina    0    

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

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

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

14.01.2019    10495    MariaTemchina    13    

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

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

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

10.01.2019    13234    chavalah    123    

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

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

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

16.11.2014    28943    raiml    46    

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

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

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

26.12.2018    10176    1c-intelligence    7    

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

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

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

19.12.2018    10188    MariaTemchina    24