Привет, я — Лёша, и я люблю веб. Иногда это даже взаимно.
В жизни часто бывает, что едва ты начинаешь думать, что наконец стал разбираться в чём-то, что-нибудь происходит и оно говорит тебе: “Нет”. И это не всегда плохо.
Например, я думал, что более-менее знаю, как нужно писать код, пока не написал свой плагин. И это очень сильно поменяло мой подход к программированию.
В этой статье я хочу поделиться моделью организации взаимодействия и управления 20 продуктовыми командами, работающих на одну цель, на примере одного из крупных маркетплейсов страны, куда меня пригласили, чтобы построить эффективные и управляемые процессы создания продукта.
Меня зовут Игорь Симаков, я тимлид Java-разработки в команде Маркетплейс Банки.Ру. Сегодня на практическом примере разберу использование UNIT-тестирования. Оно применяется как для тестирования состояния, так и для проверки поведения кода. В этом материале сосредоточусь на последнем аспекте. Покажу, как использовать JUnit, Mockito и AssertJ для тестирования кода, а также JaCoCo для оценки покрытия тестами на примере простого мини-сервиса.
Эта статья основана на моем внутреннем воркшопе, который я проводил для своих коллег. В моем репозитории на GitHub можно ознакомиться с текстом доклада. Там содержится обзор основных понятий, используемых в статье, а также подробное описание инструментов.
Статья является шуткой и представляет собой анти-стратегию к успеху для тимлида.
Если читателям понравится, выпущу анти-гайд для управленцев более высоких уровней (руководителей тимлидов).
Если ты уже следуешь гайду, срочно обратись за помощью к руководителям и друзьям и спроси, что они делают вместо того, что здесь написано.
Если твой друг или руководитель следует гайду – попроси его обратиться за помощью (или сообщи его руководителю, что твой босс следует этому гайду и помощь нужна тебе).
Погружаемся в корпоративный ад на 3, 2, 1...
Экстремальное программирование (XP) — это одна из методологий Agile. Несмотря на название, некоторые практики уже стали стандартом в индустрии — например, рефакторинг и непрерывная интеграция. XP сосредоточена на упрощении процесса разработки, минимизации документации и максимизации обратной связи от заказчиков.
Скрайбинг — это метод визуализации идей, процессов и другой информации через рисунки, символы и текст. Но это не просто рисунки, а целенаправленное создание визуальных записей, которые способствуют лучшему пониманию, запоминанию и обобщению сложных концепций. Скрайбинг делает информацию более доступной, превращая абстрактные идеи в конкретные, легко воспринимаемые визуальные образы.
Скрайбинг применяют в разных сферах, начиная от повседневных заметок и заканчивая стратегическими сессиями в крупных компаниях. В статье мы поговорим о применении скрайбинга в ИТ. В мире, где сложность проектов постоянно растёт, а команды становятся всё более мультидисциплинарными, скрайбинг становится незаменимым инструментом для планирования, разработки и коммуникации. Он позволяет структурировать требования проекта, визуализировать архитектуру систем, проектировать пользовательские интерфейсы и сценарии использования продукта. Благодаря скрайбингу сложные технические идеи становятся понятными не только для специалистов, но и для клиентов, что значительно улучшает взаимопонимание и облегчает процесс разработки.
Я пришла в проектный менеджмент, именно в продуктовую разработку, когда это ещё не было мейнстримом. А в данный момент изумляюсь тому, во что превратилась отрасль.
Куда делись мои старые коллеги? Умные ребята, горящие своим делом, которые и меня учили, и прекрасно справлялись со своими проектами. Куда делись люди, на которых я хотела быть похожей в профессиональном плане? У которых можно спросить и проф.совет, и обменяться опытом? И почему сейчас вокруг нет больше таких коллег? Почему более опытные по возрасту и стажу коллеги совершают ошибки незаинтересованных случайных новичков?
Постоянно всплывают такие вопросы. За время работы я сменила приличное количество компаний — все крупные, с большими разработческими и ИТ‑отделами. И начинала я работать в подобных же компаниях. Вот только качество проектного менеджмента стерлось со временем. И работать в такой среде достаточно неприятно.
Мало того, что коллеги не стараются делать хорошо. Они просто не стараются вообще что-то делать
Какие перлы мочат современные ПМ и к чему это приведет, по моему мнению — далее в этой статье.
Я считаю, что планирование — полезный навык. Это касается не только производственной, но и любой деятельности, в которой хочется достигать более быстрого и, главное, стабильного прогресса.
Невозможно просто так взять и научиться проплывать 10 км, если вы не можете пока одолеть и одного бассейна. Но если подготовить адекватный план тренировок, вы сами не заметите, как шаг за шагом придете к нужному результату.
Моя компания непрерывно растет уже много лет. Меня попросили поделиться, как устроен процесс годового планирования в нашей компании. Собрал свой опыт в один лонгрид.
У руководителей, как и у обычных специалистов, бывают самые разные проблемы: с хардами, софтами, мотивацией и прочим.
Самая неприятная ситуация возникает, когда личные ценности и майндсет человека сильно расходятся с работой, которую ему приходится выполнять. Если работа не подходит человеку из‑за конфликта с личными свойствами и мотивацией, это не исправить обучением. Если такой человек — руководитель, будет страдать он и все вокруг него.
После ошибочных назначений на должность отличные сотрудники демотивируются, выгорают в щепки и демеджат всех своих подчинённых и смежников. Не потому, что они недостаточно умны или старательны, а потому, что им каждый день приходится делать вещи, которые они ненавидят или фундаментально не могут делать.
Если ты уже давно и успешно руководишь командами, эта статья вряд ли откроет тебе что‑то новое. Если ты — инженер и думаешь, стоит ли переходить в управление или руководитель, сомневающийся, стоит ли конкретного человека делать лидом — приходи под кат.
Там я поделюсь мыслями о том, какая мотивация и ожидания от управленческой работы приводят или не приводят людей к успеху. Буду рад, если мой пост снизит количество боли и плохих карьерных решений у классных ребят.
Привет, Хабр!
В разработке есть две вечные проблемы: написать код, который работает, и убедить коллег, что код надо писать именно так. Вторая, пожалуй, посложнее будет.
Сегодня я предлагаю обсудить более общий вопрос — выбор технологии для проекта в целом. Наверняка вам приходилось не раз отстаивать свое мнение в подобных спорах. Это как выбирать пиццу для большой компании, где у каждого свой вкус. Кому‑то нужна классика, кому‑то экзотика, а кто‑то без острого перца жить не может. Так как же убедить команду, что ваша технология — самая подходящая и сделать это без лишних споров и обид? Ох… Это сложно. Но не невозможно. Итак, давайте для начала определимся, есть ли у вас разрешение на ношение огнестрельного оружия? (От этого будет очень сильно зависеть аргументация.) Ну а если без шуток, для себя я выделил три этапа внедрения новой технологии.
Привет, Хабр. Меня зовут Марина Заботина, я аккаунт-директор в диджитал-агентстве Далее. Сегодня хочу поднять животрепещущую тему — зачем и как прокачивать технический бэкграунд проджект-менеджеру. В статье будут результаты опроса, который я провела среди разработчиков и ПМов, моя личная история прокачки. В финале отдаю глоссарий терминов для новичков.
Сегодня мы попробуем разобраться и дать ответ на часто возникающий вопрос.
Как правильно создавать задачи?
Из-за санкций зарегистрировать аккаунт разработчика в App Store становится если не наказанием, то как минимум испытанием. Прочитайте эту инструкцию, прежде чем приступить к созданию Apple Developer. Рассказываем про нюансы с регистрацией и оплатой лицензии юридического лица.
Канбан-метод помогает повысить управляемость и предсказуемость поставок, а также выстроить сквозной производственный процесс поиска и поставки ценности клиентам найти и устранить слабые места в процессах создания и развития продукта.
Сказ о том, как мы, дата-сайентист и аналитик данных, на троих с ChatGPT, без программиста и девопса, создали сервис пересказа новостей TechMix с текстом и озвучкой. ChatGPT писал код, а мы ему только поддакивали.
Авторы: Эдуард Ланчев, Илья Кузнецов, ChatGPT
Набирая миллионную аудиторию, любой сервис организует работу десятков и сотен разработчиков для поддержки и развития такого проекта. Но их работа видна конечному пользователю лишь через призму маркетинга и поддержки. В данной статье расскажу, как по следам багов в OZON можно наблюдать деградацию взаимодействия подобных сервисов с их клиентами и обесценивание труда программистов.
Почему работа всегда сложнее чем кажется в начале?
Почему с течением роста проекта производительность программиста падает?
Почему читать код сложнее чем писать?
Многие модели, практики и методы управления были созданы и развиты на основе инициатив в области информационных технологий. Появился Agile, развилась дисциплина управления проектами, а бизнес-операции и цифровые операции стали единым целым.
Внедрение любой корпоративной информационной системы достаточно продолжительно по срокам и требует большого объема трудозатрат [1]. В среднем необходимо около одного года на имплементацию ERP‑системы, а трудозатраты проектной команды со стороны исполнителя обычно колеблются в диапазоне 1000–3000 человеко‑дней. Объем трудозатрат фактически задает перечень тех работ, которые обязуется выполнить интегратор для заказчика. Чем больше объем выполняемых работ, тем актуальнее становится задача по их группировке для более качественного планирования, исполнения и контроля.
Именно по этой причине в [2] выделяют уровни внедрения, такие как: процессы, приложения, данные и техника, а также управление проектом и изменениями. Однако и этого деления бывает недостаточно, так как каждый уровень по прежнему остается достаточно трудоемким. По этой причине в работах [3–4] вводится понимание концепции реализации содержания проекта, заключающейся в выделении наиболее критичных областей проекта внедрения ERP‑систем, а также предложении состава и порядка выполнения работ для каждой из областей. Примерами областей служат задачи, относящиеся к анализу, проектированию, разработке, миграции, тестированию и др.
Состав работ определяется путем рассмотрения всевозможных способов, методов и подходов, позволяющих достигнуть необходимого результата с минимальными рисками задержки продуктивного старта ERP‑системы. Объем необходимых работ дает возможность увидеть плановую потребность в человеческих ресурсах, что критично для формирования ресурсного плана проекта, а состав задач обеспечивает понимание всех тонкостей реализации предстоящего проекта. В рамках текущей статьи мы рассмотрим все критичные области ERP‑проекта и суммируем способы реализации задач каждой из областей, тем самым расширяя содержание работы [4].
