Scrum: серебряной пули не существует

Публикация № 1106675 12.08.19

Анализ и управление - Управление проектом

Гибкие методологии набирают популярность среди команд разработчиков. Но применять их в том варианте, который предлагается первоначально, не всегда удается. О своем опыте работы по Scrum в условиях, когда нет проектов, рассказал на конференции Infostart Event 2018 Education ведущий разработчик 1С одной из крупнейших торговых сетей Дмитрий Кирилкин.

Справка:

Дмитрий Кирилкин, ведущий разработчик 1С в торговой сети Реми (Владивосток). С недавнего времени также является техническим лидером во внутреннем отделе разработки. Ранее 6 лет руководил отделом информационных технологий большой фармацевтической компании. В ИТ работает почти 20 лет.

 

Предисловие

Сразу хочу сказать, что мой доклад не имеет никакого отношения к команде «Серебряная пуля». Она существует, все в порядке, не переживайте.

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

 

Что заставило нас искать новые подходы?

Компания Реми – это крупнейшая сеть продуктовых супермаркетов на Дальнем Востоке. Штат компании составляет более 3 тысяч человек в разных городах Дальневосточного региона. Компания начала бурно развиваться в последние два года, до этого отдел разработки состоял из двух человек – меня, как программиста 1С, и руководителя. И в течение буквально 6 месяцев количество разработчиков в отделе увеличилось с 1 до 4.

 

 

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

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

Также в нас проснулся интерес к новому, желание работать не как все. С  течением времени появляется такое понятие, как профессиональное выгорание. Становится неинтересно работать, потому что все одно и то же – 1С, задачи, бухгалтерия, управленческий учет. Хочется попробовать что-то другое, хочется работать не как все. Тем более, есть такой миф в профессиональной среде разработчиков, что программисты 1С «несерьезные», мол, у нас даже код на русском языке. Поэтому хотелось приобщиться к профессиональному сообществу разработчиков.

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

 

 

 

Знакомство с методологией

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

И что мы сделали? Первым делом мы просто поставили Kanban-доску, насоздавали там колонок «бэклог», «в работе» и «готово». Начали вписывать задачки, двигать их по колонкам. Вот, вроде как, мы по Kanban и работаем.

Но дальше предстояло разобраться, что собой представляют Scrum и Agile. Долгое время, честно сказать, я считал, что Agile – это такое же направление гибких методологий разработки, как и Scrum. Я думал, что в Agile одни правила, а в Scrum – другие. Но потом я разобрался, что Agile – это в принципе сборник методологий, некий брендбук, если можно так сказать, в котором собрано все, что касается гибких методик экстремального программирования. А Scrum и Kanban – это просто направления Agile.

 

 

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

 

 

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

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

 

 

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

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

 

Что мы хотели получить от методологии?

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

Второе ожидание – самоорганизация команды. Бизнес растет, задачи становятся все сложнее, а в будущем нас, разработчиков, станет намного больше. Поэтому нам нужны были методы, которые позволили бы команде самоорганизовываться, потому что управлять напрямую командой из 20 человек уже практически невозможно. А Scrum благодаря заложенным в него методам внутренней самоорганизации эту проблему прекрасно решает, как нам казалось.

Повышение производительности. Про это ожидание говорить много не буду, только напомню сакраментальное: «делать два раза больше за половину времени».

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

 

 

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

 

 

 

Популяризация и понимание Scrum в команде

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

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

И я говорю ребятам: “Представьте, что у вас есть ограниченный отрезок времени – две недели – спринт, в течение которого вы выполняете задачи, набранные на этот отрезок времени, не больше. По окончании этого отрезка времени вы набираете на следующие две недели новый пул задач, которые вы тоже обязаны выполнить за две недели. И тогда вы сможете сказать пользователю, что у нас через две недели закончится спринт, и в следующий спринт мы возьмем твою задачку, соответственно, мы сможем с ней начать работать через 2 недели, а закончим ее еще через 2 недели. То есть ты получишь свой функционал через месяц. Пользователя такой ответ устроит? Скорее всего, да. Потому что он и не ждал от нас конкретной даты, все ведь понимают, что это практически невозможно угадать.”

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

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

 

 

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

- что ты сделал вчера?

- что ты сделал сегодня? (именно в прошедшем числе)

- что тебе мешает?

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

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

Самый сложный из них был, конечно, последний – «что тебе мешает?».

 

Выбор владельца продукта и Scrum-мастера

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

Со Scrum-мастером тоже все не так просто. По определению, это человек, который следит за ходом проекта. А проекта у нас нет, у нас есть 4 конфигурации. Как быть? Пришли к тому, что у нас есть не 4 конфигурации, а проект, состоящий из 4 конфигураций. И первое время у нас Scrum-мастер просто обеспечивал проведение коротких собраний (митингов), задавал три вопроса. И это был дежурный программист. У нас есть в команде обязательно дежурный программист на неделю, он эту неделю и являлся временным Scrum-мастером.

И опять же, это определение «помогает устранять мешающие препятствия команде». Какие препятствия? Это было неясно. Потом мы поняли, что все-таки это человек, который должен следить за процессом разработки программного обеспечения в команде. Сейчас это у нас один из опытных разработчиков, который смотрит, все ли гладко сейчас в протекающем процессе, в протекающем спринте, не скопились ли задачи в тестировании, что с ними делать, сразу же об этом сигнализирует и пытается моментально выработать решения. Также, этот человек в свое время предложил перейти с недельных спринтов (я чуть позже об этом скажу) на двухнедельные. Потому что за недельный спринт мы просто не успевали сделать необходимый функционал, было слишком мало времени. И именно этот человек будет следить за тем, дал ли переход на двухнедельные спринты какой-то результат.

И чем хорош Scrum: никто не заставляет людей выполнять какие-то роли. Как правило, они сами на себя их берут, потому что им становится интересно.

 

 

 

Обязательные события Scrum

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

 

 

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

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

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

Ретроспектива спринта – это очень сложно. Картинка отлично демонстрирует, как это происходило у нас в первое время.

 

 

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

 

 

Что касается обзора спринта. К сожалению, из-за того, что у нас нет продукта, как такового, а 4 отраслевые конфигурации, в спринт, как правило, набирается огромное количество всевозможных маленьких задач. И провести какое-то демо с пользователями практически не представляется возможным. Они просто не придут: кто-то находится на Сахалине, кто-то в Хабаровске. Поэтому на обзоре спринта, мы, как правило, рассказываем про технические решения для своих же коллег в отделе. Допустим, внедрили мы в продакшене автодеплой, рассказали, как это работает. Внедрили интеграционную шину, рассказали, как работает. Т.е. основная цель обзора спринта у нас – это повышение информированности сотрудников команды, чтобы они знали, чем мы занимаемся.

 

Новый подход к работе с задачами

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

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

 

 

 

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

Оценка задача в Story Points нужна обязательно. В начале начинаешь без нее, но тут Scrum изящно решает проблему оценки задач, он вводит ее относительность. Мы используем числа Фибоначчи для оценки задач, точность при этом нам не очень нужна, потому что главное – оценить количественную сложность задачи.

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

 

 

 

Жизненный цикл задачи

Расскажу про жизненный цикл наших задач. На картинке – вид текущей Scrum-доски, которая у нас есть сейчас на проекте.

 

 

 

Там есть колонки: «нужно сделать», «непонятное ТЗ», «тестирование не пройдено», «в работе», «ожидает тестирования», «идет тестирование», «готово». И задача в принципе так и движется – слева направо. У нас все задачи тестируются разработчиками. Разработчик, который выполнил задачу, перемещает ее в «ожидает тестирования», а следующий разработчик берет эту задачу в тест. Этим мы решаем две задачи. Во-первых, проводится сразу же Code review, во-вторых, разработчик сразу же входит в курс дела, и в случае если тестирование не пройдено, он переводит задачу в «тестирование не пройдено», пишет свои комментарии. Поскольку в задаче сохраняется последний исполнитель и последний тестировщик, это позволяет не передавать работу из рук в руки. И когда в следующий раз разработчик увидит задачу в колонке «тестирование не пройдено», он ее вернет назад в работу, а в тестирование эту задачу возьмет тот сотрудник, который ее проверял до этого.

Еще. Спринту желательно создавать цель. Этим занимается Scrum-мастер. Но из-за того, что у нас 4 конфигурации, мы не можем часто задавать цель спринта.

 

Программное обеспечение, которое мы используем

Последнее, о чем хочу рассказать – программное обеспечение, которое мы используем: Jira Software, Confluence, а со стороны пользователей – 1С:Документооборот.

 

 

 

Дополнительное программное обеспечение – GIT, OneScript, Jenkins.

 

 

 

Вместо заключения

К чему мы пришли?

  • Повысился уровень самоорганизации в команде.
  • Коллективная ответственность за результат растет. Действительно, приятно видеть, как люди сами, никто их не просит, берут работу, предлагают что-то новое.
  • События Scrum создают атмосферу, в которой каждый сотрудник чувствует, что он работает не один.
  • Благодаря  оценке задач в Story Points мы знаем производительность команды и можем более точно оценить свои возможности.

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

 

 

 

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

 

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

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

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. capitan 2304 12.08.19 17:58 Сейчас в теме
Ну вот ... сейчас еще скажут что Деда Мороза не существует.
2. пользователь 12.08.19 19:48
Сообщение было скрыто модератором.
...
3. taishy 52 14.08.19 10:23 Сейчас в теме
В фильме "Терминал" есть сцена, где два прораба наблюдают за тем, как работает их подчиненный. Один другого спрашивает: "Спроси его, чем он занимается", на что второй отвечает "Если я его спрошу об этом, то буду выглядеть идиотом, потому что хороший руководитель всегда знает чем занимается его подчиненный". Как вы к этому относитесь?
7. RustIG 1652 15.08.19 21:58 Сейчас в теме
8. taishy 52 16.08.19 09:25 Сейчас в теме
(7) Минус поставил кто-то на мой комментарий
4. taishy 52 14.08.19 10:40 Сейчас в теме
В целом, полезная статья, очень заинтересовало, спасибо!
Выделил для себя:
наличие технического задания вообще не является обязательным для того, чтобы приступить к разработке какого-то функционала, достаточно видеть небольшую область впереди себя, и когда мы к ней придем, на следующем шаге мы увидим еще какую-то область, и, соответственно, таким образом техническое задание будет уточняться в процессе реализации
5. taishy 52 14.08.19 10:48 Сейчас в теме
И еще несколько вопросов назрело:
1. Есть ли у вас горячая линия/техподдержка ? (К кому пользователи обращаются за консультацией?)
2. Как рождается задача? Кто является постановщиком?
3. Есть ли аналитик?
6. RustIG 1652 15.08.19 21:54 Сейчас в теме
Оставьте свое сообщение

См. также

Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

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

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

12.01.2023    2851    MariaTemchina    28    

18

На что похож ваш продукт: на Аквариум или на Муравейник? 

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

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

27.12.2022    1646    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

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

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    1722    user1576201    6    

16

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

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

05.08.2022    9017    Evil Beaver    16    

97

Технология вялых проектов

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

Не все ж такие молодцы.

11.05.2022    4493    1c-intelligence    49    

41

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

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

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free)

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

02.02.2022    7727    denisgalimoff    3    

23

7-ой PMBOK® Guide: Есть ли там что-то действительно полезное?..

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

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

07.09.2021    8555    MariaTemchina    0    

20

Новый PMBoK 7®: Неужели заговор его составителей против простых людей все-таки раскрыт?

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

Некоторое время назад один из моих читателей в своем письме предположил, что есть настоящий заговор у тех, кто пропагандирует изучение PMBoK®.

30.07.2021    8735    MariaTemchina    13    

23

Как приручить драконов. История построения экосистемы на основе 1С

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

Многие задачи интеграции и мониторинга не имеют стандартных решений в среде 1С. О том, как команда 1С-ников смогла организовать успешный симбиоз учетной системы и системы тысяч внешних устройств, на INFOSTART MEETUP Новосибирск.Online рассказал TeamLead и специалист по внедрению компании ИнфоСофт Григорий Шатров.

14.05.2021    4441    G.Shatrov    6    

19

Пришиваем хвост: нужен ли Эджайл в 1С или глупости это всё?..

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

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    7567    MariaTemchina    86    

27

Распознавание и загрузка документов в 1С Промо

Универсальная программа-обработка для распознавания любых сканов или фото первичных документов в 1С (счета-фактуры, УПД, ТТН, акты и тд). Точность распознания до 98%.

от 11 рублей

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

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

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

16.02.2021    4391    MariaTemchina    45    

33

Как бороться с соблазном объять необъятное, или Канбан-система в проектах 1С

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

На первом онлайн-митапе в Санкт-Петербурге Мария Темчина рассказала участникам митапа о принципах работы Канбан-системы в проектах 1С. Как выбрать инструмент для работы по Канбану, с чего начать при внедрении, и какие игры помогут освоить эту систему.

12.02.2021    4720    MariaTemchina    17    

25

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

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

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

10.02.2021    6181    andironenko    17    

51

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

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

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

09.12.2020    2902    MariaTemchina    3    

30

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

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

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

03.12.2020    6118    MariaTemchina    9    

34

Видеокурс-практикум: как подготовить и написать ТЗ, ЗНР, ЧТЗ. Промо

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

3 500 рублей

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

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

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

18.11.2020    7335    MariaTemchina    9    

26

Как создать коробочный программный продукт

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

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

05.10.2020    4283    primat    2    

25

Стыд и Скрам: взгляд глазами собственника из IT-шников

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

Не все, кто употребляют понятия Agile и Scrum, понимают, что они означают. О том, насколько в реальном мире автоматизации бизнеса на платформе 1С применимы гибкие подходы к разработке ИТ-продуктов на конференции Infostart Event 2019 рассказал основатель и соучредитель группы компаний WiseAdvice Иван Тягунов.

18.09.2020    5588    IvanAT1981    5    

20

Советы начинающим РП: Подводим итоги шляпной вечеринки 

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

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

15.09.2020    3327    MariaTemchina    5    

23

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

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

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

11.09.2020    4300    alexandr.blinov    17    

40

Работа с 1С:Аналитика Промо

Онлайн-курс предусматривает изучение возможностей системы “1С:Аналитика”, которая работает как составная часть платформы “1С:Предприятие” и обеспечивает оперативный просмотр и анализ необходимых данных.

4500 рублей

Как продвигать авторские конфигурации 1С

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

Конфигурации 1С продвигать на рынке самостоятельно нелегко. Мало того, что нужно развивать продукт, чтобы удовлетворять потребности клиентов и выгодно отличаться от конкурентов, нужно еще заниматься его популяризацией, продажами и поиском проектов для внедрений. Большую часть этой работы готов взять на себя Инфостарт. Авторам останется только разработка, развитие и внедрение. Чем именно готов помочь Инфостарт, рассказал руководитель корпоративного отдела компании Рамин Курбанов. 

07.09.2020    3213    RKurbanov    3    

22

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

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

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

04.09.2020    5052    MariaTemchina    30    

44

Матрица СКГ как инструмент разработки деловой модели

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

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

24.07.2020    3484    Soliton    10    

19

Видеозаписи открытых вебинаров Марии Темчиной

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

В этой публикации решила собрать здесь видеозаписи открытых вебинаров с моим участием. Чтобы были в одном месте, ибо их не всегда просто найти на Инфостарте. "Всё, что вы хотели узнать...", "Лучшие морковки проектов внедрения...", "Путь джедая в управлении проектами..." и так далее.

21.07.2020    4196    MariaTemchina    1    

32

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

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

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

26.06.2020    5692    1c-intelligence    17    

56

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Наиболее типичные ошибки при оценке работ в проектах 1С

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

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке. Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, - то вам будет полезно понять методы оценки работ. Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет». Типичные ошибки распределю по классам.

13.06.2020    3503    Koder_Line    9    

26

Как воспитать в себе РП? Часть 2. Растим ведущего руководителя проектов

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

Теперь поговорим про роль ведущего руководителя проектов, задающего и формирующего политику управления проектами в компании.

08.06.2020    8338    MariaTemchina    0    

20

Как воспитать в себе РП? Часть 1

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

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

01.06.2020    9334    MariaTemchina    4    

23

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

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

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

25.05.2020    7169    sapervodichka    1    

56

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

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

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

18.05.2020    13621    MariaTemchina    34    

45

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

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

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

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

23.03.2020    8253    MariaTemchina    26    

33

Визуализация фич Vanessa Automation в StoryMapper

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

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

21.03.2020    5014    oleynik.dv    7    

23

Как завершать проекты в срок

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

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

10.03.2020    5787    VLikhobabin    6    

27

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

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

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

03.03.2020    10577    VLikhobabin    44    

67

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

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

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

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

23.01.2020    46703    MariaTemchina    12    

36

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

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

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

04.01.2020    7324    capitan    52    

24

BDDSM-практики, или 50 оттенков желтого

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

В статье описаны практические результаты применения методики BDDSM на отдельно взятом РЕАЛЬНОМ проекте поддержки.

26.12.2019    13162    Mistress_A    28    

80

Про одну Тётю

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

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

24.12.2019    7693    1c-intelligence    33    

27

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

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

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

14.10.2019    6634    chavalah    16    

27