Иногда в мире менеджмента встречается выражение:
"Команда работает как часы!"
Некоторые руководители, директора, и даже владельцы бизнеса думают:
"Процессы настроили? Настроили. Продукт выдают? Выдают. Деньги капают? Капают. Отлично, дело сделано!"
Иногда такие люди называют себя эффективными менеджерами.
А правда ли дело сделано?
Внедрение крупных программных систем подразумевает использование различных методологий имплементации, например: Accelerated SAP, Microsoft Dynamics Sure Steps или Oracle Unified Method. Прикладная методология, предлагаемая по умолчанию вендором программного продукта, детализирует одну из трех классических моделей имплементации: каскадную, итерационную или спиралевидную. Помимо этого существуют определенные правила по управлению проектами вне зависимости от его содержания, которые называют PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами) [1].
PMBoK подразумевает выделение в проекте ряда ключевых параметров, каждый из которых необходимо планировать, выполнять и осуществлять его мониторинг. Любые отклонения параметров от плановых значений требуют корректировочного действия. Свод знаний разработан американским институтом PMI и имеет длительную историю. На начало 2022 года в русскоязычной литературе доступна PMBoK шестой версии, а в англоязычной – седьмой. Каждая версия PMBoK дополняется новыми подходами, так ранее широкой огласке получили механизмы искусственного интеллекта в управлении проектами, сейчас же активно обсуждается применение принципов гибкой разработки Agile.
Для прочтения книга PMBoK весьма сложна. Определенно знакомство со сводом знаний необходимо начинать, предварительно реализовав хотя бы один проект, в противном случае вы не поймете посыл книжки. В контексте данной статьи, мы ограничимся рассмотрением ERP-проектов. Использование PMBoK в проектах имплементации корпоративных информационных систем выглядит выигрышным, по крайней мере, это позволяет структурировать характеристики проекта и вести их непрерывный контроль. Существенным упущением PMBoK является отсутствие рекомендаций по способам обработки отклонений, что противоречит циклу Деминга [2]. Вполне возможно, это было сделано сознательно, так как невозможно предложить универсальные механизмы для всех предметных областей проектов.
Когда люди, не знакомые с разработкой и процессами в ней предлагают свои фреймворки для измерения или улучшения эффективности, ничего хорошего из этого не выходит. Поговорим о том, почему ничего хорошего не может выйти и из метода McKinsey, которые решили, что придумали универсальный подход, и воодушевлены продвигать его в массы. А еще поговорим о том, как и зачем на самом деле стоит подходить к оценке продуктивности разработчиков, чтобы не сломать уже работающие механизмы.
Раньше я был вовлечён в создание приложений со стороны банка, а теперь занимаюсь ими со стороны компании-разработчика. Делюсь: вот что думает бизнес, когда решается на новое приложение.
Это вторая и последняя часть ответа нас двоих Gergely Orosz и Kent Beck:
на статью McKinsey «Да, вы можете измерить продуктивность разработчиков программного обеспечения».
Мы считаем, что фрейморк который предлагает McKinsey является ошибочным и наверняка приведет к обратным результатам. Такой фреймворк, скорее всего, принесет гораздо больше вреда, чем пользы организациям – и инженерной культуре в компаниях, и на устранение ущерба могут потребоваться годы.
Что делать, если ценности клиента для вас очень важны, но при этом вам приходится работать в компании, чья внутренняя культура этого не приветствует?
11 лет своей жизни посвятил Amazon (2009-2020 гг.), а затем еще 4 года проработал в Google (2020-2024 гг.). В обеих компаниях я встречался и работал с людьми, которые искренне заботились о клиентах, однако сами культуры при этом разительно отличались.
Привет, Хабр! Меня зовут Максим Приходский, я архитектор R-Style Softlab и сегодня хочу рассказать вам о проекте создания архитектурного репозитория в git на базе PlantUML.
Привет, Хабр! В этой статье мы расскажем о мобильном приложении для обмена местоположением «Кто/Где». Оно позволяет в реальном времени видеть на карте, где находятся друзья и близкие, быстро и удобно назначая с ними встречи. Важный момент: обмениваться координатами можно только с теми пользователями, которые дали на это согласие. Подробности, как всегда, под катом.
Давайте вспомним 90-е годы (неужели я настолько стар?). Тогда наша мантра гласила, что IT должно быть согласовано с бизнесом. Сегодня технологии стали настолько важны, что, похоже, теперь бизнес должен быть согласован с технологиями. Я никогда не видел постановку вопроса "одно против другого", когда речь шла об IT и бизнесе, ведь независимо от того, как вы на это смотрите, они должны быть согласованы. Вот здесь и приходят на помощь дорожные карты (roadmap).
Составление дорожных карт — это процесс определения будущего направления развития. Вы наверняка уже слышали о дорожных картах продуктов или технологий. Возможно, вы даже слышали о дорожных картах возможностей. Но как вам наметить эти дорожные карты, на чем фокусируется каждая из них и как они работают вместе? Именно об этом мы и поговорим сегодня.
Дорогие читатели, я видела, что на Хабр уже есть статья посвященная SDLC (и не одна), однако, этой статьей я хочу привлечь внимание ИТ-менеджеров, ничего об этом не знающих или знающих поверхностно. Напишу немного по-своему, так как я объясняла джунам, админам проекта и нетехническим специалистам, работающим непосредственно с разработкой программных продуктов. Было, что и на весь проектный офис рассказывала…
Да, такое встречается и нередко, что менеджер проекта, именно посвященного разработке ПО, не знает, что такое цикл разработки программного продукта (=SDLC), не понимает, зачем это знать, как с этим работать и к чему применять. К сожалению, это не только Джуны, мне встречались менеджеры уровнем и повыше, которые работают в командах разработки и не понимают их процессов. «Зачем, от этого же ничего не зависит» – говорили мне они…да ещё как зависит вообще-то.
Без этого понимания вы делаете то, не знаю что и команду ведете туда, не знаю куда. Просто вот 1 случай: мой коллега, находимся на одинаковых позициях, взял и запланировал значит проект вот так: аналитика-тестирование-разработка-выкатка в прод. Никого ничего не смущает?) Это не какой-то там мем, это случай из жизни. Ну, что получилось? Тестировщик пришел, а тестировать нечего…ведь даже ничего ещё не разработано, протестировал бизнес-требования и ТЗ и был таков, а в прод выкатили поставку с критическими ошибками, все встало. Был конфузец.
В моем понимании, это знание относится к категории базовых. Вот у каждой профессии есть своя база. Большая проблема, что считается, что спокойно можно зайти без этой базы в проектный менеджмент и вести свои проекты. Но, незнание базы, элементарных основных вещей, взаимосвязей, схем работы, методов и методологий, приводит вот к таким смешным ошибкам.
В данной статье я расскажу о стадиях SDLC, как это применять в жизни и как можно улучшить свою работу с помощью данного инструмента.
Привет, я — Лёша, и я люблю веб. Иногда это даже взаимно.
В жизни часто бывает, что едва ты начинаешь думать, что наконец стал разбираться в чём-то, что-нибудь происходит и оно говорит тебе: “Нет”. И это не всегда плохо.
Например, я думал, что более-менее знаю, как нужно писать код, пока не написал свой плагин. И это очень сильно поменяло мой подход к программированию.
В этой статье я хочу поделиться моделью организации взаимодействия и управления 20 продуктовыми командами, работающих на одну цель, на примере одного из крупных маркетплейсов страны, куда меня пригласили, чтобы построить эффективные и управляемые процессы создания продукта.
Меня зовут Игорь Симаков, я тимлид Java-разработки в команде Маркетплейс Банки.Ру. Сегодня на практическом примере разберу использование UNIT-тестирования. Оно применяется как для тестирования состояния, так и для проверки поведения кода. В этом материале сосредоточусь на последнем аспекте. Покажу, как использовать JUnit, Mockito и AssertJ для тестирования кода, а также JaCoCo для оценки покрытия тестами на примере простого мини-сервиса.
Эта статья основана на моем внутреннем воркшопе, который я проводил для своих коллег. В моем репозитории на GitHub можно ознакомиться с текстом доклада. Там содержится обзор основных понятий, используемых в статье, а также подробное описание инструментов.
Статья является шуткой и представляет собой анти-стратегию к успеху для тимлида.
Если читателям понравится, выпущу анти-гайд для управленцев более высоких уровней (руководителей тимлидов).
Если ты уже следуешь гайду, срочно обратись за помощью к руководителям и друзьям и спроси, что они делают вместо того, что здесь написано.
Если твой друг или руководитель следует гайду – попроси его обратиться за помощью (или сообщи его руководителю, что твой босс следует этому гайду и помощь нужна тебе).
Погружаемся в корпоративный ад на 3, 2, 1...
Экстремальное программирование (XP) — это одна из методологий Agile. Несмотря на название, некоторые практики уже стали стандартом в индустрии — например, рефакторинг и непрерывная интеграция. XP сосредоточена на упрощении процесса разработки, минимизации документации и максимизации обратной связи от заказчиков.
Скрайбинг — это метод визуализации идей, процессов и другой информации через рисунки, символы и текст. Но это не просто рисунки, а целенаправленное создание визуальных записей, которые способствуют лучшему пониманию, запоминанию и обобщению сложных концепций. Скрайбинг делает информацию более доступной, превращая абстрактные идеи в конкретные, легко воспринимаемые визуальные образы.
Скрайбинг применяют в разных сферах, начиная от повседневных заметок и заканчивая стратегическими сессиями в крупных компаниях. В статье мы поговорим о применении скрайбинга в ИТ. В мире, где сложность проектов постоянно растёт, а команды становятся всё более мультидисциплинарными, скрайбинг становится незаменимым инструментом для планирования, разработки и коммуникации. Он позволяет структурировать требования проекта, визуализировать архитектуру систем, проектировать пользовательские интерфейсы и сценарии использования продукта. Благодаря скрайбингу сложные технические идеи становятся понятными не только для специалистов, но и для клиентов, что значительно улучшает взаимопонимание и облегчает процесс разработки.
Я пришла в проектный менеджмент, именно в продуктовую разработку, когда это ещё не было мейнстримом. А в данный момент изумляюсь тому, во что превратилась отрасль.
Куда делись мои старые коллеги? Умные ребята, горящие своим делом, которые и меня учили, и прекрасно справлялись со своими проектами. Куда делись люди, на которых я хотела быть похожей в профессиональном плане? У которых можно спросить и проф.совет, и обменяться опытом? И почему сейчас вокруг нет больше таких коллег? Почему более опытные по возрасту и стажу коллеги совершают ошибки незаинтересованных случайных новичков?
Постоянно всплывают такие вопросы. За время работы я сменила приличное количество компаний — все крупные, с большими разработческими и ИТ‑отделами. И начинала я работать в подобных же компаниях. Вот только качество проектного менеджмента стерлось со временем. И работать в такой среде достаточно неприятно.
Мало того, что коллеги не стараются делать хорошо. Они просто не стараются вообще что-то делать
Какие перлы мочат современные ПМ и к чему это приведет, по моему мнению — далее в этой статье.
Я считаю, что планирование — полезный навык. Это касается не только производственной, но и любой деятельности, в которой хочется достигать более быстрого и, главное, стабильного прогресса.
Невозможно просто так взять и научиться проплывать 10 км, если вы не можете пока одолеть и одного бассейна. Но если подготовить адекватный план тренировок, вы сами не заметите, как шаг за шагом придете к нужному результату.
Моя компания непрерывно растет уже много лет. Меня попросили поделиться, как устроен процесс годового планирования в нашей компании. Собрал свой опыт в один лонгрид.
У руководителей, как и у обычных специалистов, бывают самые разные проблемы: с хардами, софтами, мотивацией и прочим.
Самая неприятная ситуация возникает, когда личные ценности и майндсет человека сильно расходятся с работой, которую ему приходится выполнять. Если работа не подходит человеку из‑за конфликта с личными свойствами и мотивацией, это не исправить обучением. Если такой человек — руководитель, будет страдать он и все вокруг него.
После ошибочных назначений на должность отличные сотрудники демотивируются, выгорают в щепки и демеджат всех своих подчинённых и смежников. Не потому, что они недостаточно умны или старательны, а потому, что им каждый день приходится делать вещи, которые они ненавидят или фундаментально не могут делать.
Если ты уже давно и успешно руководишь командами, эта статья вряд ли откроет тебе что‑то новое. Если ты — инженер и думаешь, стоит ли переходить в управление или руководитель, сомневающийся, стоит ли конкретного человека делать лидом — приходи под кат.
Там я поделюсь мыслями о том, какая мотивация и ожидания от управленческой работы приводят или не приводят людей к успеху. Буду рад, если мой пост снизит количество боли и плохих карьерных решений у классных ребят.
