Pull to refresh
10
0
Максим Евстратов @Locolind

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

Send message

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

Level of difficultyEasy
Reading time1 min
Views5.3K

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

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

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

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

Пройти опрос
Total votes 9: ↑7 and ↓2+5
Comments43

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

Level of difficultyEasy
Reading time5 min
Views11K

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

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

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

Читать далее
Total votes 12: ↑6 and ↓60
Comments10

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

Reading time5 min
Views3.4K

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

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

Читать далее
Total votes 7: ↑5 and ↓2+3
Comments8

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

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

image

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

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

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

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

Читать дальше →
Total votes 11: ↑10 and ↓1+9
Comments9

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

Reading time6 min
Views8.4K

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

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

Подготовленная означает, что большинство членов команды не просто знакомы с практиками и ценностями Agile, но владеют ими.
Читать дальше →
Total votes 14: ↑12 and ↓2+10
Comments3

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

Reading time9 min
Views19K


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

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

Ниже результаты моих теоретических и практических исследований в поисках ответов. Постарался изложить их просто, без «мозговзрыва» присущего этой теме.
Читать дальше →
Total votes 28: ↑22 and ↓6+16
Comments25

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

Reading time16 min
Views28K


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


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

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

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

Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.
Читать дальше →
Total votes 20: ↑15 and ↓5+10
Comments23

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

Reading time6 min
Views13K

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

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

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

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

Эти истории демонстрируют собой ответ на вопрос «Зачем изучать продукты конкурентов?», а следующий вопрос «Как анализировать и сравнивать свой ИТ-продукт с продуктами конкурентов?» На meetup-е мы обсудили кейсы участников, их я вам и презентую.
Читать дальше →
Total votes 9: ↑8 and ↓1+7
Comments2

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

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

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

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


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

Это лишь один из способов составить план выпуска релизов и уверен, что существует много других вариантов. Я использовал этот подход со многими командами разного размера во многих проектах различной величины и сложности. Во многих случаях я его расширял и дополнял, но основы всегда оставались прежними и хорошо работают. Буду рад комментариям о том, как вы это делаете со своими командами.
Читать дальше →
Total votes 13: ↑12 and ↓1+11
Comments3

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

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

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


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

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

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

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

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



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

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

Reading time4 min
Views12K


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

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

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

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

Это Марк

Читать дальше →
Total votes 36: ↑24 and ↓12+12
Comments9

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

Reading time6 min
Views13K
О том, когда задач больше чем ресурсов на их выполнение, очередь задач со временем увеличивается и часть из них можно смело назвать «дурацкими».
Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.
О
  • управлении потоком задач на разработку,
    Как избавится от «дурацких» задач?
  • управлении расходами на разработку,
    Как определить и выбрать самые выгодные задачи?
  • распределении ограниченных ресурсов.
    Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?

Читать дальше →
Total votes 27: ↑25 and ↓2+23
Comments36

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

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

image

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

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

  • Как в этом объеме документов найти те, что описывают работу определенного функционала системы?
  • Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?
  • Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?
Total votes 20: ↑15 and ↓5+10
Comments27

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity