Статьи / Профиль Locolind / Хабр

Максим Евстратов @Locolind

Управление разработкой ИТ-продуктов

Профиль Публикации 13Комментарии 75Закладки 413

Locolind 16 фев в 05:11

Опрос «Где ведёте свой список дел?»

Простой

1 мин

5.9K

GTD*

Аналитика

Недавно выпустил статью про свой опыт ведения списка дел на бумаге. В карму прилетело несколько минусов с причиной "статья \ тема не для хабра".

Хоть ведение списков дел формально относится к хабу GTD (Getting Things Done \ Методика повышения личной эффективности) и у него 7ЗК подписчиков, мне стало интересно сколько хабровчан ведёт списки дел и как мы это делаем. Вдруг минусующие ребята правы и подтема ведения списка дел неинтересна читателям хабра.

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

Приглашаю вас его пройти.

Пройти опрос

Locolind 10 янв в 13:31

Ведение списка задач на бумаге: личный опыт

Простой

5 мин

11K

GTD*

Ретроспектива

Думаете начать вести свой список дел на бумаге? Или уже ведёте его, но столкнулись со сложностями?

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

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

Locolind 27 дек 2022 в 09:32

Обучение должно быть неотъемлемой частью ежедневной работы

5 мин

3.4K

Управление разработкой*Управление проектами*Agile*Управление продуктом*

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

Адресована агентам изменений: Скрам Мастерам, Эджайл Коучам и иже с ними, так как хочу поделится с коллегами по цеху накопленным опытом и осмыслением профессии в которой работаю = чем заниматься скрам мастеру \ эджайл коучу \ агенту изменений в компании. Будет интересна и широкому кругу.

Locolind 6 апр 2020 в 11:39

Будни Scrum-Мастера: трансформация команды и себя

5 мин

3.4K

Agile*Профессиональная литература*Управление разработкой*Учебный процесс в IT

Бывало ли с вами такое, что вовремя общения, чтения или изучения чего-то будто осеняет, какая-то из старых или нынешних ситуаций в буквальном смысле предстаёт в новом свете? Со мной это постоянно случается, в этот раз при чтении книги “Азбука системного мышления” Донеллы Медоуз.

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

Один из призывов и советов Донеллы в книге — обращать внимание не на конкретные События, а на Поведение Системы в целом и на то, как устроена, её Структура.

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

Здесь и далее команда и система будут синонимами.

Читать дальше →

Locolind 12 апр 2018 в 19:22

Как я учусь практикам и ценностям Agile

6 мин

8.4K

Agile*Управление персоналом*Учебный процесс в IT

Под катом обзор и выводы с ретроспективы MeetUp-а про командную работу и рефлексию, который 3 апреля провела Елена Литвинова.

Для меня он стал демонстрацией как обычная команда (далее команда 1.0), отличается от подготовленной (команда 2.0).

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

Читать дальше →

+10

Locolind 15 июл 2017 в 15:52

Стоимость качества в разработке программного обеспечения

9 мин

20K

Agile*Терминология ITУправление продуктом*Управление проектами*Управление разработкой*

Что такое качество в разработке ПО?
Во сколько нам обходится некачественное ПО?
Кто отвечает за качество?

Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ~~ошибки~~ софт для Заказчиков.

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

Читать дальше →

+16

Locolind 10 июн 2017 в 14:57

Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов

16 мин

29K

ERP-системы*Терминология ITУправление проектами*Управление разработкой*

Как возникла необходимость отойти от классической Каскадной Модели жизненного цикла разработки

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

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

Большой пример: только оказавшись под санкциями и цене нефти в 50 долларов за баррель (против 110 ранее) руководство страны перешло от рассуждений и неспешных телодвижений к активным действиям по развитию высокотехнологичной экономики.

Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.

Читать дальше →

+10

Locolind 26 апр 2017 в 16:38

Анализ и сравнение своего ИТ-продукта с продуктами конкурентов

6 мин

13K

Развитие стартапаУправление продажами*Управление продуктом*Управление проектами*

Кто мы (наш продукт) на этой картинке?

Это результаты работы моего стола на meetup-e Products Moscow Meetup Group от 20 апреля 2017 года, который прошёл в формате «world cafe».

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

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

Ещё один пример можно увидеть в сериале «Силиконовая долина», когда в 8 серии 1 сезона, Гевин Бэлсон из Hooli презентует на TechСrunch Disrupt как они взломали алгоритм сжатия Pied Piper, тем самым убив уникальность последнего, лишив права быть первым и технологического преимущества.

Эти истории демонстрируют собой ответ на вопрос «Зачем изучать продукты конкурентов?», а следующий вопрос «Как анализировать и сравнивать свой ИТ-продукт с продуктами конкурентов?» На meetup-е мы обсудили кейсы участников, их я вам и презентую.

Читать дальше →

Locolind 4 апр 2017 в 16:27

Гибкое планирование выпуска релизов 101 (на основе Excel)

13 мин

16K

Agile*Управление продуктом*Управление проектами*Управление разработкой*

Перевод

Предисловие переводчика: Недавно я рассказал о том, как реализовать процедуру планирования выпуска релизов по продуктам с помощью семейства продуктов Atlassian и дал ссылки на статьи как сделать тоже самое в Team Foundation Server и Redmine.

А что делать если компания не дозрела купить JIRA, TFS или Redmine, как обойтись только Excel-ем?

И эта статья о том как это сделать.

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

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

Читать дальше →

+11

Locolind 25 фев 2017 в 16:24

Реализация процедуры «Планирование выпуска релизов по продуктам» инструментами семейства Atlassian

7 мин

20K

Agile*Управление продуктом*Управление проектами*Управление разработкой*

Это мой доклад с Meetup-а Московской Atlassian User Group от 1 марта 2017 года

Контекст и задача

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

Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.

Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.

Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.

Бизнес-логика

Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).

+11

Locolind 19 ноя 2016 в 09:34

Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)

4 мин

12K

Карьера в IT-индустрииТерминология ITУправление продуктом*Управление проектами*Управление разработкой*

Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга... Joel Spolsky

Статья Джоэла о Пяти мирах (программного обеспечения) вышла в 2002 году. За прошедшие 14 лет успели образоваться новые миры: Мобильные приложения и Облака, — но соль статьи осталась неизменной.

Одна и та же технология в разных условиях будет давать разную эффективность.

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

Представьте, мы на Земле, наш друг Марк на Марсе. У нас стоит одна и та же цель, вырастить в своём Мире урожай картошки. Технологию будем использовать одинаковую «посадка в грунт», а результаты получим разные так как влияние факторов/переменных разное для каждого из Миров. Это кажется очевидным, но факты из жизни говорят об обратном.

Это Марк

Читать дальше →

+12

Locolind 7 ноя 2016 в 10:08

Управление задачами на разработку. История из жизни

6 мин

13K

Agile*ERP-системы*Управление продуктом*Управление проектами*Управление разработкой*

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

Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.

управлении потоком задач на разработку,
Как избавится от «дурацких» задач?
управлении расходами на разработку,
Как определить и выбрать самые выгодные задачи?
распределении ограниченных ресурсов.
Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?

Читать дальше →

+23

Locolind 13 окт 2016 в 12:20

Каким должно быть ТЗ на Корпоративную ИС?

5 мин

27K

Анализ и проектирование систем*Проектирование и рефакторинг*Управление разработкой*

Из песочницы

Recovery Mode

Представьте, что у вас есть корпоративная информационная система в развитие которой вкладывается 200+ млн. рублей ежегодно. С момента внедрения документация на систему превратилась из одного Технического задания на 600 страниц в 300 Технических заданий, у каждого из которых есть дополнение в количестве от 1 до 10 штук, и теперь она занимает объем 3 офисных шкафов и это ещё не конец… Фабрика по производству ПО исправно и ритмично (с периодичностью в месяц) выпускает обновление системы и документирует изменения.

Ребята, которые разрабатывали 34-й ГОСТ явно не рассчитывали на то, что дело может принять такой оборот. Да и книги по гибким методологиям разработки тоже не дают каких-то рекомендаций как с этим быть.

Всё что нам казалось не очень важным тогда, со временем и в масштабе приобрело вид серьезной проблемы.

Как в этом объеме документов найти те, что описывают работу определенного функционала системы?
Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?
Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?

+10