Agile для внутренней разработки

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

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

Речь пойдет о том, что такое гибкие методологии. Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года).

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

 

Как правило, все начинается с того, что у компании есть разработчик, который разбирается в бизнес домене, общается с пользователями. Этот разработчик для компании совсем «свой».

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

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

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

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

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

Обычно в этой ситуации между заказчиком и разработчиком возникает некоторый конфликт:

  • Заказчик говорит, что «Долго делают». А разработчик говорит – «Непродуманные требования».
  • Заказчик говорит – «Срывают сроки». Разработчик отвечает – «Новые задачи».
  • Заказчик говорит – «Низкое качество». Разработчик отвечает – «Не знают, чего хотят».
  • Заказчик говорит – «Постоянные баги». Разработчик отвечает – «Сроки с потолка».

Это – некоторый классовый конфликт, классовая борьба, котораяможет длиться довольно долго, и у этой классовой борьбы есть два варианта развития.

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

  • Заказчик говорит – «Почему не готово?» Вы отвечаете – «Приоритеты поменялись», «Новые требования», «Программиста забрали на другой проект».
  • Заказчик говори – «Чтобы завтра было!». Вы отвечаете – «Придется урезать тестирование».

  • Ну и на следующий день у нас спрашивают – «Почему баги?»

Это первый вариант. Он довольно грустный.

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

  • Когда разработчики говорят – «Ничего делать не будем, пока не согласуем требования».
  • Или когда они направляют любые заявки в «Комитет по управлению изменениями». Что это такое? Это такая координационная группа, которая собирается раз в месяц. Если они в процессе своего обсуждения «запрувят» changerequest по поводу конкретной заявки, тогда разработчики будут что-то делать.
  • Или когда разработчики говорят – у нас сейчас фаза разработки архитектуры. И во время этой фазы ничего в течение двух месяцев не делают, потому что говорят, что сначала должна быть разработана архитектура. То есть, на клеточном уровне они сильно заняты, по крайней мере те, кто что-то пишет. Но по большому счету в этот период ничего не делается.
  • Есть еще фаза тестирования. Когда разработчики говорят, что перед тем, как выложить разработку в Production, нужно еще запустить фазу тестирования.
  • В принципе, у заказчика есть один-единственный шанс отбиться. Этот шанс называется «приемка у заказчика».Но и тут можно промахнуться, если вдруг окажется, что разработчики выставили требование проводить приемку только по тестовым сценариям, которые заранее согласовали.

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

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

Здесь и приходят на помощь технологии разработки Agile как реальная возможность достичь компромисса между заказчиками и разработчиками.

 

Разработка по гибким методологиям 

 

При разработке по ТЗ получается примерно такая ситуация:

  • У вас есть ТЗ, над которым вы работаете в течение долгого времени. Вы можете даже по Agile и Scrum работать по ТЗ. Приходите в какую-то точку.
  • Потом идет сдача заказчику. После сдачи заказчику вы готовы в разумных пределах переписать что-то из сделанного. Потому что даже если вы в чем-то чуть-чуть потеряли, главное, что контракт подписали, проект сдали.
  • Потом возникает обратный путь, который называется «Эксплуатация». Там уже идет changerequest от бизнеса, и нам приходится в чем-то двигаться в другую сторону.Мы перепиливаем то, что было неправильно реализовано.

Так вот, разработка по технологии Agile – это попытка «упростить» ситуацию, двигаясь через частые промежуточные показы заказчику. На самом деле за счет этого получается существенная экономия за счет разницы между выполненными требованиями по ТЗ и реальными потребностями бизнеса, что показано на этом слайде. Эта разница называется «ложная загрузка» (failuredemand).

Нам не приходится писать лишний код, не приходится этот лишний код поддерживать, не приходится платить за это деньги нашим программистам. Нам не приходится работать в режиме «аврала» и строчить по 300-500 строчек кода в день. В среднем, нормальный промышленный стандарт – около 100 строчек кода в день. Быстрее и не нужно, можно просто попытаться срезать углы. А для этого достаточно делать регулярные показы заказчику. Это могут быть даже не показы, нам просто нужна качественная грамотная обратная связь.

 

Scrum

 

Есть разные методологии. Работа по методологии Scrum – это когда у вас есть беклог (backlog) продукта, в котором описана задача, которую вы собираетесь сделать, некий «план». Вы этот план бьете на подзадачи, рассчитанные, например, на две недели. В конце работы над  подзадачей вы получаете готовый продукт, который можно показать заказчику. В идеале, вы этот продукт для заказчика раскатываете в Production, чтобы получить еще более качественную обратную связь. И потом проводите ретроспективу, обсуждаете, как вам улучшить свой продукт.

Большую часть времени работа в Scrum ведется вокруг доски, которая называется Scrumboard (или Taskboard).

Выглядит это примерно так, как на слайде.

  • Слева у нас находится список задач, который нужно сделать – BackLog
  • В середине располагаются задачи, которые вы собираетесь делать в эту итерацию – ToDo
  • Дальше – те задачи, которые уже обрабатываются – InProgress
  • Потом - CodeReview
  • Тестирование – Test
  • И готовое – Done

Ну и в идеале, при работе над итерацией продукта, задачи постепенно переезжают слева направо.

Проводят такие совещания – это называется StandUp. Человек, который их проводит, называется Scrum Master – по сути, он помогает команде разбирать задачи. Вообще в методологии Agile команда обязательно в полном составе должна присутствовать при разборе задач на таком StandUp. Пропустить никто не может. Как правило, эта методика получается продуктивной. Выбор задач получается контекстным, более эффективным в зависимости от конкретной сегодняшней ситуации.

 

Kanban

 

Еще есть такая методология, которая называется Kanban. Методологии Kanban и Scrum – это не то же самое. В Kanban разница в том, что там нет фиксированного времени на итерацию, просто задача переезжает слева направо. Идея такая же, как и в Scrum: ведется очередь задач, вы разрабатываете для них приемочные критерии, у вас разработка, тестирование, deploy и готово. Так же для разбора и обсуждения задач проводят StandUp.

В результате, на доске задач у вас отражается некоторый естественный жизненный цикл того, как люди реально работали.

 

Фаза «Анализ»

 

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

  • Например, он скажет вам: «выстрели мне в ногу!» И вы ему «да не вопрос!» - и стреляете.
    И он теперь: «у меня нога болит, поправь». Обычно разработчики на это отвечают: «у меня такая же нога – у меня не болит».
  • А если вы спросите: «зачем тебе, заказчик, стрелять себе в ногу?» Он может ответить: «она у меня чешется».
    А вы ему: «так давай я тебе ее почешу». И заказчик удивится: «а что, так можно было, что ли? Замечательно! Мне нравится!»

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

Конечно, это возможно только при условии, если вы делаете анализ более-менее качественно.

 

Фаза «Тестирование»

 

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

Особенно дорого поправлять баги, которые находят пользователи. Большинство компаний, где зрелость процессов не очень высокая, полагается в тестировании на пользователей. Им кажется, что это бесплатно. На самом деле, тестирование на пользователях – это намного более дорого, чем тестирование своими силами.

Опять-таки, тестирование своими силами приводит к сокращению failureload.

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

 

Нужно ли ТЗ?

 

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

 

Критерии готовности

 

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

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

Как мы это делаем в гибких методологиях? Мы просто договариваемся о критериях готовности – Definition of Done. Это такая договоренность внутри команды, как правило, между тремя сторонами – заказчик, команда и руководство (потому что руководство тоже заинтересовано).

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

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

 

Поток задач

 

 

Конечно, всем этим хотелось бы научиться управлять.

 

Вот этот график на верхнем слайде называется Cumulative Flow – поток задач нарастающим итогом. На нем показано, как в ваш HelpDesk прилетают заявки, и с какой скоростью вы эти заявки делаете. Видите, что здесь у вас есть проблемы? Дальше эти проблемы будут становиться только хуже и хуже. Чем дальше, тем сильнее вы будете отставать. Соответственно, стоит задача попытаться этот график как-то сузить.

 

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

 

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

 

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

 

 

Инструменты управления сроками

 

На этом слайде показана диаграмма Burn-downchart. В методологии Scrum мы используем для этого понятие Velocity – скорость команды, сколько человеко-дней за эту итерацию команда успела сделать. Это не человеко-дни потраченного времени, это человеко-дни вашей оценки планируемых работ. У вас есть backlog, есть какие-то задачи. Вы их оценили в человеко-днях. Сколько оцененных задач вы за итерацию успели сделать? Какую сумму планируемых работ необходимо перенести на следующую итерацию? Таким образом, можно прогнозировать, сколько нам нужно будет делать потом.

Например, вы знаете, что вы сделали за итерацию 20 человеко-дней, а весь backlog у вас на 200 человеко-дней. Это означает, что примерно за 10 итераций вы проект доделаете, конечно, если вам не навалят новых задач.Это неплохо работает. Ситуацию можно прогнозировать с точностью до 5%.

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

Поэтому еще один комикс: «Используй velocity для прогнозирования сроков окончания проекта» – «Я и так знаю сроки окончания проекта. Мне уже руководство их сказало».

Ну и что, что оно тебе их сказало? Ты все равно же должен попытаться понять – успеваешь ли ты уложиться в эти сроки или не успеваешь.

 

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

 

Заключение

 

Ну и напоследок я хотел бы просто сказать, что «есть многое в мире, друг Горацио»…

Есть много практик, подходов, которые можно и нужно пробовать, смотреть, как они работают в вашей конкретной команде. Вы можете погуглить их по ключевому слову Software Engineering. Посмотрите, как они работают в вашей реальной ситуации. Вполне возможно, что по принципу Парето, 20% из них из них могут принести вам 80% полезности.

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

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

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

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. mulla1979 9 30.09.15 09:24 Сейчас в теме
Спасибо, очень познавательно!
2. Кузьмич 188 30.09.15 09:33 Сейчас в теме
ууу ... сколько много "умных слов". Сразили.
Software Engineering

Все, о чем тут расписано определяется "устаревшим" понятием "экстремальное программирование". Только напридумывали новые технологии и методологии. А суть осталась там же.

зы. Презентация конечно труд еще тот. Снимаю шляпу за оформление.
Silenser; ZLENKO; +2 Ответить
3. Designer1C 336 30.09.15 10:12 Сейчас в теме
Тема важная. Для меня самое интересное в статье : как не делать лишнюю работу.
Есть просьба использовать русские слова вместо слэнга.
Либо в начале статьи писать словарик. Лично мне было бы более понятно.
sergey512; c1nil; +2 Ответить
4. maxx 905 07.10.15 21:41 Сейчас в теме
А при каких размерах проектов стоит применять подобнве технологии?
Например, у меня часто есть проекты на 200-300 часов срок исполнения от 2 нед до месяца. Разработчиков от 2 до 6. Список задач составлен, бюджет задачи в среднем 4-5 часов ( отчеты, печ.формы, мелкие механизмы)

Есть ли время на большое количество показов?
5. ВикторП 219 28.08.16 08:42 Сейчас в теме
3.То что здесь написано - не XP(экстремальное программирование..) Agile Scrum- про управление и организацию, а xp- про инженерные практики,то же парное программирование, к примеру
6. ВикторП 219 28.08.16 08:44 Сейчас в теме
4.Для вас подходит хорошо. Заодно скорость команды узнаете
7. brr 179 04.09.17 12:11 Сейчас в теме
А для этого достаточно делать регулярные показы заказчику. Это могут быть даже не показы, нам просто нужна качественная грамотная обратная связь.


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

Нужное подчеркнуть, отсутствующее добавить
8. Yashazz 3255 07.09.17 11:25 Сейчас в теме
Много картинок, много пыщь-пыщь, всё очень красиво, наглядно, увлекательно, и как всегда на практике заканчивается полным уродством, провалом и жестью немерянной. Любимый приём всех этих многознатцев-консультантов от эйджила - напустить пыль в глаза, очаровать сладкими сказками, как всё будет круто, потом сгрести бабла и сбежать. А реальный проект потом имеет только проблемы.

Я б за попытку распространять все эти agil'ы, особенно применительно к разработке 1С, сажал бы как за вредительство и мошенничество.
9. KSy 07.09.17 16:27 Сейчас в теме
(8) Поддерживаю.
Пусть они без ТЗ с частыми показами заказчику попробуют хотя бы УТ 11 (я не беру ERP) с доработками по планированию закупок/продаж+бюджетирование внедрить.

Такие статьи в стиле "кукушка хвалит петуха..." проходят на ура на хабре.
10. karapuzzzz 63 17.11.17 17:35 Сейчас в теме
(9)Для внедрения продукта используйте Waterfall, а для разработки - Agile. В чем проблема? Каждая методология имеет свою применимость. Хороший PM будет применять то, что необходимо именно в этом случае.
11. karapuzzzz 63 17.11.17 17:36 Сейчас в теме
(8)А какую методологию вы используете?
12. Yashazz 3255 21.11.17 17:34 Сейчас в теме
(11) Никакую. Мы методологиями не заморачиваемся, мы работаем. Дело делаем. Конфигурации создаём, доработки выполняем. Некогда нам, знаете ли, дурью маяться.
К наступлению авралов, частоте факапов, проблемам с клиентами итд - наличие либо отсутствие упомянутой "методологии" и прочей заумной хрени не имеет, как показывает опыт, ни-ка-ко-го отношения.

То же экстремальное, допустим, случается, но от него, по здравому размышлению, ничего бы не спасло. Ибо бизнес захотел всё готовое позавчера, и точка, и плевать ему на все спринты, канбаны, эйджилы и прочая)
13. karapuzzzz 63 21.11.17 22:06 Сейчас в теме
(12)
Ибо бизнес захотел всё готовое позавчера, и точка, и плевать ему на все спринты, канбаны, эйджилы и прочая

Та и не должен бизнес об этом знать. Точнее, желание бизнеса готового на вчера не должно встречать "у нас же спринт" или что-то подобное. Бизнес захотел - делаем. Добавляем новые задачи в спринт и делаем. Эджайл именно так и говорит: "Готовность к изменениям важнее следования первоначальному плану"
Методологиями не заморачиваются, методологиями следуют. Ни один проект не может существовать без управления. А значит, или вы не ведёте проектную деятельность (что мало вероятно при разработках конфигураций) или ведёте, но вы не в курсе.
14. Rico17 30 11.10.18 14:39 Сейчас в теме
Методология нужна когда "все плохо" ;)
Когда "мощность" разработчика не справляется с необходимым объемом в необходимые заказчику сроки.
Оставьте свое сообщение

См. также

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

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

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

04.04.2019    12393    67    Infostart    18    

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

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

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

08.06.2020    3658    0    stepan96    11    

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

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

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

25.05.2020    4419    0    sapervodichka    1    

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

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

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

18.05.2020    9696    0    MariaTemchina    33    

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

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

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

23.03.2020    4809    0    MariaTemchina    24    

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

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

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

03.03.2020    5548    0    VLikhobabin    44    

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

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

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

23.01.2020    10600    0    MariaTemchina    8    

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

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

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

24.01.2019    9413    0    user809424    11    

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

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

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

09.01.2020    5772    0    roman72    0    

Про одну Тётю

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

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

24.12.2019    6261    0    1c-intelligence    32    

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

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

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

14.10.2019    5610    0    chavalah    16    

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

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

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

29.06.2017    33359    0    1СERP    79    

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

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

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

19.09.2019    11622    0    ogroup    163    

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

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

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

16.09.2019    8978    0    GSoft    15    

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

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

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

30.08.2019    10643    0    SergeyN    6    

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

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

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

09.06.2017    30278    0    1СERP    175    

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

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

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

20.08.2019    8043    0    KoldunOne    7    

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

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

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

16.08.2019    7760    0    Hissin    18    

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

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

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

24.06.2019    6287    0    sbase    9    

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

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

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

18.04.2017    31103    0    1СERP    189    

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

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

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

19.06.2019    9545    0    FB_10160810658600104    62    

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

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

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

18.06.2019    7085    0    MariaTemchina    8    

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

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

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

31.05.2019    8252    0    MariaTemchina    23    

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

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

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

10.04.2017    30986    0    1СERP    107    

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

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

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

14.05.2019    10692    0    1c-intelligence    121    

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

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

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

06.05.2019    7106    0    MariaTemchina    8    

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

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

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

04.05.2019    8597    0    1c-intelligence    39    

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

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

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

03.04.2017    41661    0    1СERP    231    

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

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

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

15.04.2019    11011    0    MariaTemchina    15    

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

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

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

13.02.2019    7934    0    chavalah    22    

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

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

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

12.02.2019    9469    0    MariaTemchina    20    

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

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

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

23.02.2017    27056    0    Gavrik    10    

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

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

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

04.02.2019    9651    0    1c-intelligence    64    

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

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

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

31.01.2019    7983    0    MariaTemchina    0    

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

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

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

14.01.2019    9784    0    MariaTemchina    13    

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

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

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

17.06.2016    39540    0    raiml    37    

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

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

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

26.12.2014    44009    0    CheBurator    64    

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

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

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

1 стартмани

14.09.2015    35851    0    axxell    15