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

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

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

15
Гибкие методологии набирают популярность среди команд разработчиков. Но применять их в том варианте, который предлагается первоначально, не всегда удается. О своем опыте работы по 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. Больше статей можно прочитать здесь.
Приглашаем вас на новую конференцию INFOSTART EVENT 2019!

 

15

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

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

См. также

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

Статья no Нет файла Бесплатно (free) Управление проектом

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

14.10.2019    2843    chavalah    16       

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

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

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

Статья no Нет файла Россия Бесплатно (free) Управление проектом

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

19.09.2019    7878    ogroup    156       

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

Статья no Нет файла Бесплатно (free) Управление проектом

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

16.09.2019    5280    GSoft    14       

Онлайн-курс "Технология выполнения проектов ERP-класса – процессный подход". Третий поток. Курс проходит с 21 января по 18 марта 2020 года. Промо

Курс разработан Внедренческим центром «Раздолье». Курс предназначен для подготовки аналитиков, архитекторов и руководителей проектов автоматизации процессов управления с использованием комплексных ИТ-систем (1С:ERP, 1С:УХ, 1С:КА, 1С:УТ). В основе курса лежит методика применения процессного подхода.

9000 рублей

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

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Управление проектом СППР

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

30.08.2019    5150    SergeyN    4       

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

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

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

16.08.2019    4581    Hissin    18       

Cashback 35% при покупке 1С лицензий на счет INFOSTART.RU с 27.11 по 04.12 Промо

Оформляете заказ на 1С лицензии или конфигурации. Получаете 35% от стоимости на счет в профиле INFOSTART.RU. Выбираете сервисы и продукты на сумму кэшбэка.

Как заработать миллион или История успешного сотрудничества 46

Статья Программист Нет файла Бесплатно (free) Управление проектом

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

05.08.2019    4846    karpik666    77       

Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0"). Обновлен до версий КА 1.1.115.х, УПП 1.3.127.х! Промо

Разработка позволяет перенести остатки по всем счетам бух.учета в программу "1С:Бухгалтерия предприятия 8", ред. 3.0 на выбранную дату начала ведения учета. Также переносятся документы за период и вся необходимая справочная информация. Правила оперативно обновляю при выходе новых релизов. Рассылка обновлений правил бесплатно в течение 12 месяцев. Есть видеодемонстрация проведения переноса данных. Конфигурации при использовании обмена остаются полностью типовыми. Перенос данных возможен в Бухгалтерию 3.0 версии ПРОФ, КОРП или базовую.

24700 руб.

Бизнес-аналитика с помощью Power BI 68

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

11.07.2019    7606    pbazeliuk    18       

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

Статья Бизнес-аналитик Руководитель проекта Нет файла УУ Финансовый учет и бюджетирование (FRP) Бесплатно (free) Управление проектом

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

28.06.2019    3944    SergeyN    1       

Очный семинар по регулярному менеджменту Александра Фридмана "Вы или Хаос", 12 декабря 2019 г. , Санкт-Петербург Промо

Семинар по регулярному менеджменту от Александра Фридмана для собственников, первых лиц и топов. Технология управленческого планирования, комплексного управления временем и другими ресурсами, выполнением поручений, делами, информацией, контактами (встречи-звонки-почта).

от 11000 до 29000 рублей

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

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

24.06.2019    3260    sbase    9       

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

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

18.06.2019    4419    MariaTemchina    8       

Перенос данных УПП 1.3 => ERP 2 (ЕРП) / УТ 11 / КА 2.х (обработка переноса документов, остатков и справочников из "1С:Управление производственным предприятием, ред. 1.3" в ERP / УТ 11 / КА 2). Обновлен до УПП 1.3.127.х, КА 2.4.10.х и ERP 2.4.10.х! Промо

Обработка позволяет переносить из УПП 1.3 в ERP 2 документы за выбранный период и остатки. Типовая обработка от фирмы 1С документы не переносит. Также исправлены ошибки типовой обработки. При выходе новых релизов обновление высылается бесплатно в течение года. Разработка будет полезна фирмам-франчайзи, которые периодически выполняют такой перенос данных для заказчиков. Вы можете один раз приобрести обработку переноса, и потом бесплатно получать обновления при выходе новых релизов конфигураций 1С.

29700 руб.

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

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.05.2019    4743    MariaTemchina    23       

Как продать проект в 3 раза дороже и нанести клиенту пользу, выполнив не внедрение... 21

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

27.05.2019    4718    cybrat    9       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Что важно, а что - срочно? 21

Статья no Нет файла Бесплатно (free) Управление проектом

Поговорим о приоритетах

20.05.2019    4966    1c-intelligence    16       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

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

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

06.05.2019    4539    MariaTemchina    8       

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

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

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

04.05.2019    5468    1c-intelligence    39       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

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

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

15.04.2019    7510    MariaTemchina    15       

Перенос данных КА 1.1 => ERP 2 (ЕРП) (обработка переноса документов, остатков и справочной информации из "1С:Комплексная автоматизация, ред. 1.1" в "1С:ERP Управление предприятием, ред 2"). Обновлен до КА 1.1.115.х и ERP 2.4.10.х Промо

Обработка позволяет переносить из КА 1.1 в ERP 2 документы за выбранный период и остатки. Типовая обработка от фирмы 1С документы не переносит. Также исправлены ошибки типовой обработки. При выходе новых релизов обновление высылается бесплатно в течение года. Разработка будет полезна фирмам-франчайзи, которые периодически выполняют такой перенос данных для заказчиков. Вы можете один раз приобрести обработку переноса, и потом бесплатно получать обновления в случае выхода новых релизов конфигураций 1С.

29700 руб.

Стыд и Скрам, часть вторая 21

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

14.03.2019    8578    MariaTemchina    47       

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

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

13.02.2019    5099    chavalah    22       

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

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

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

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

12.02.2019    6648    MariaTemchina    20       

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

Статья no Нет файла Бесплатно (free) Управление проектом

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

04.02.2019    6350    1c-intelligence    64       

Онлайн-интенсив "Бизнес-процессы для подготовки к экзамену 1С:Специалист по платформе" 12 декабря 2019 г. Промо

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

777 рублей

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

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

31.01.2019    5464    MariaTemchina    0       

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

Статья no Нет файла Бесплатно (free) Управление проектом

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

24.01.2019    6872    user809424    11