Управление проектами *

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

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

Корпорация Microsoft еще весной 2022 года объявила о приостановке бизнеса в России. Соответственно, пользователи из РФ не могут покупать лицензии на программное обеспечение компании, включая продукты для управления проектами и портфелями проектов MS Project Server. Наверное, у некоторых компаний из России еще работают облачные версии платформы, но только до момента завершения срока действия подписки.

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

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

Я не очень понимаю, почему об этом мало кто рассказывает.

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

Почему модные и молодёжные аджайл-команды релиз не делали? Потому что у них было готово всё кроме одной мелочи — например, разработанных и согласованных архитектурных документов на решение с инетрпрайз архитектором и безопасником. То есть процесс, который можно условно назвать «ГОСТ», приходил к ним в лице суровых грустных мужиков. И заставлял их проходить все этапы согласований, начиная с оценки возможного риска и заканчивая какими-то «совершенно ненужными» тестами, согласованиями требований с юристами и прочей хтонью, которая нормальному человеку покажется адом. Но именно по этому аду нужно было пройти, сделать с десятка два документов, согласовать каждый и только после этого выходить в продакшен. Где-то месяца через два.

Думаю, вы и сами представляете, как оно происходит в банках. Именно поэтому многие разработчики <sarcasm>так стремятся</sarcasm> в них работать.

Когда я прикоснулся в Газпромбанке к организации производства, то как раз застал несколько «ГОСТ-команд» с совершенно безнадёжным TTM и много аджайл-команд, бьющихся в истерике от требований.

Привет! Меня зовут Валерий, я руковожу группой QA Fullstack компании SimbirSoft. В сфере тестирования чаще всего выделяют группы QA-специалистов и SDET. Но сейчас многие компании задумываются об оптимизации расходов, особенно это актуально для проектов с длительным периодом эксплуатации, вроде небольших монолитов или внушительных размеров систем с множеством интеграций и микросервисов. Рано или поздно наступает момент, когда требуется подключать специалистов, которые не только хорошо разбираются в продукте и могут тщательно его протестировать, но и тех, кто могут писать автотесты. Убить двух зайцев сразу помогут QA фулстеки.

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

Ещё один небольшой pet-проект: про кафе и коворкинги на солнечном Кипре. "Рабочие места" для цифровых кочевников ヽ(。_°)ノ

Делюсь процессом разработки, фичами и граблями. Общий подход к разработке прагматичен и аналогичен предыдущему проекту.

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

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

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

Так бывает, что надо команду передать от одного скрам-мастеру другому (например, в ситуации с переводом, увольнением или уходом в декрет). Я в таких ситуациях была дважды, когда уходила и возвращалась из декрета, и выработала оптимальный порядок при передаче/приёмке скрам-команды из 6 шагов. О нем и пойдет речь в статье.

У нас, в компании FINCH, у каждого из отделов есть система грейдов. Система предназначенная для оценки навыков специалистов и зарплатной вилки на которую они могут претендовать, в зависимости от выполняемых задач и роли занимаемой в проекте.

До последнего времени у отдела менеджеров не было такой системы и это вызывало непредсказуемые решения в управлении кадрами и распределении проектов.

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

Привет, Хабр! Меня зовут Герман Холмов, долгое время я работал в Positive Technologies в должности Digital Marketing Director. На Хабре многие знают эту компанию, а если нет - то вот ее блог. Но речь сейчас не о компании, а об организации двух онлайн-ивентов для специалистов по кибербезопасности. Я вместе с командой отвечал за запуск. В ходе реализации проекта пришлось решать немало проблем, которые возникали как до организации мероприятий, так и во время. Думаю, что мой опыт будет полезен, поэтому и решил написать статью. О подробностях - под катом.

О том, что руководитель управляет знаниями, серьёзно заговорили ещё в прошлом столетии. Питер Друкер, теперь уже классик бизнес-управления, назвал стремительно растущий сегмент офисных сотрудников «работниками умственного труда». Это было в 1959 году. Вскоре он выделил шесть факторов, влияющих на их продуктивность.

Всем привет! Меня зовут Сергей, и сегодня я расскажу о том, как я искал носки мы выстраивали процессы тестирования в команде.

Исторически сложилось, что мы делаем бэкенд для мобильного приложения, из-за чего многое приходилось проверять вручную, а на автоматизацию выделялся один «технический день», когда тестировщики могли посвятить своё время задачам из бэклога QA. В принципе, этого хватало, так как в нашей молодой команде чаще всего разрабатывалась новая функциональность и не было необходимости рефакторинга, а полная функциональность проверялась на регрессе мобильного приложения. 

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

Привет, я Илья — Frontend Team Lead в Альфа-Банк. Отвечаю не только за команду, но также веду и техчасть. Как тимлид я часто задаюсь вопросом «В чем моя роль?», «Как измерить эффективность моей работы?» и «Какой профит от лидов для проекта в целом?»

Для себя я вывел определение и задачи лида. Это всего лишь мои субъективные умозаключения, и искушенной публике Хабра могут быть хорошо знакомы, иногда слишком очевидны, но…повторение мать учения, как когда-то говорили. И даже если мы сто раз что-то слышали — не значит, что мы начали это делать. То, о чем я хочу рассказать – простые шаги, которые работают только при регулярном повторении, без пропуска какого-то пункта, это важно.

Софтовые статьи обычно полны воды, поэтому, дабы её не лить, приступим. Заранее извинюсь, что букв будет много, просто это моя первая статья (не судите строго) да и накопилось много, чем хочется поделиться. Многие темы, что я подниму, можно разбирать бесконечно долго и писать на каждую по циклу статей, но, сегодня будет овервью. 

Многие, говоря про Скрам в первую очередь вспоминают про добавление событий в процессы работы команды (дейлик, планирование, обзор, ретроспектива и сам спринт). Но это лишь является верхушкой айсберга всего фреймворка.

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

В 1939 году Курт Левин проводит социальный эксперимент среди 10-летних детей с целью выявления типов лидерства и их влияния на работу в команде. Возможно, выводы Левина не будут открытием для читателей, знакомых с «Повелителем мух», однако некоторые наблюдения не перестают удивлять. Диктатура дисциплинирует, но убивает творчество; демократия плодит креативность, но уменьшает производительность, а либерализм вызывает агрессию. Так ли все однозначно? Не совсем.

Современный управеленец — это традиционный, восходящий еще к античности наставник и в то же время — менеджер эпохи развитого капитализма. Именно в кино две эти идентичности сливаются в характерного персонажа: кинематографический образ подсвечивает все грани лидерства.

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

Итак, последняя часть статьи про поиск первой работы продактом. Если вы ещё не читали, то в первой части я рассказывал про шаги перед поиском вакансии, а во второй - про отклики на вакансии и тестовое задание.

Также в канале Продактом быть я рассказываю о своём опыте в PM, и многие вещи оттуда тоже могут пригодиться на собеседованиях :)

Сегодня же расскажу про собеседования. Этот этап вызывает больше всего стресса в процессе поиска работы. И этот стресс можно кратно уменьшить, если знать, к чему готовиться.

Из чего состоят собеседования

Из моего опыта, чаще всего после тестового вас ожидает 1-2 созвона с продактами компании.

И на этих созвонах активности делятся на 3 части:

1. Знакомство, обсуждение вашей мотивации, базовой адекватности

2. Обсуждение вашего прошлого опыта в PM/смежных ролях

3. Заготовленные кейсы от нанимающей компании

Если говорить про 1 и 2 части, то тут ребята оценивают, как вы принимали решения на предыдущих местах работы/в пет-проектах. Откуда брали гипотезы, как мерили успех от запуска, как ваши решения согласовывались со стратегией компании, почему делали именно этот проект, а не другой и.т.д.

А в 3 части вам предстоит решить несколько кейсов, которые чаще всего связаны с деятельностью компании. А могут быть и не связаны. 

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

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

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

В PMBoK этому процессу уделено всего пару абзацев текста, и в данной группе процессов есть собственно только один процесс - закрытие проекта или фазы.

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