Сергей Горшенин | Бизнес-тренер |

«ИТ-проекты через призму экономической эффективности»

По каким критериям сегодня на практике осуществляется приоритезация проектов и принимаются решения об их старте / заморозке / развитии? Во-первых не всегда такие критерии существуют в компании. Согласно исследованиям последних лет только у трети крупных и средних российских компаний существует практика обязательного рассмотрения инвест-проектов в области ИТ перед запуском Во-вторых более половины компаний выполняют финансовое обоснование только некоторых ИТ-проектов или не проводят его вообще. Аналитики Gartner Group показали, что в качестве основной метрики, применяемой для оценки эффективности ИТ, чаще всего используется стоимость решения, а также показатели уровня сервиса, удовлетворенности пользователей и аналогичным "качественным" показателям. То есть чаще всего решение об инвестициях в ИТ принимается на основании стоимости решения. Поэтому в условиях жестких финансовых ограничений предпочтение отдается недорогим и краткосрочным проектам. К тому, согласно исследованиям Gartner Group, большинство ИТ-проектов оперируют ТОЛЬКО лишь качественными показателями которые сложно оценить однозначно. Об этом мы поговорим, в частности о: - чем мы управляем - о разнице между бизнес-эффективностью и эффективностью бизнеса - что лучше - результативность или эффективность - об эффективности в ИТ-проектах и ее измерении - об основных методах расчета инвестиционного анализа - о том кому нужна эффективность на самом деле - об инвесторах и спонсорах проектов - восприятии стейкхолдеров

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

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

Перейти к публикации

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

Вакансии


Программист 1С
Москва
зарплата от 100 000 руб. до 200 000 руб.
Полный день

Преподаватель 1С
Санкт-Петербург
Полный день

Удаленный ИТ-журналист
Санкт-Петербург
По совместительству

Программист 1С
Санкт-Петербург
зарплата от 80 000 руб. до 150 000 руб.
Полный день