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

Меня зовут Женя, я руководитель проектов. Хочу поделиться с Хабром кейсом моей команды: мы автоматизировали работу с обращениями клиентов в холдинге «Русклимат».

Проблема была в том, что сотрудники компании работали с большими объёмами данных в нескольких программах (служба поддержки в Naumen, претензионный отдел в 1С, сервисные центры на старом портале), из-за чего обработать и передать обращение другому подразделению было сложно.

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

Привет, Хабр!

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

Сегодня я предлагаю обсудить более общий вопрос — выбор технологии для проекта в целом. Наверняка вам приходилось не раз отстаивать свое мнение в подобных спорах. Это как выбирать пиццу для большой компании, где у каждого свой вкус. Кому‑то нужна классика, кому‑то экзотика, а кто‑то без острого перца жить не может. Так как же убедить команду, что ваша технология — самая подходящая и сделать это без лишних споров и обид? Ох… Это сложно. Но не невозможно. Итак, давайте для начала определимся, есть ли у вас разрешение на ношение огнестрельного оружия? (От этого будет очень сильно зависеть аргументация.) Ну а если без шуток, для себя я выделил три этапа внедрения новой технологии.

Всем привет! Меня зовут Фефилов Александр, я работаю в QA с 2017 года. По большей части это были компании, которые занимались аутсорсингом, но затем я присоединился к SM Lab.

Как вы уже поняли из названия поста, я расскажу о том, как взаимодействовать с заказчиком (а иногда и с заказчиками) с позиции QA‑эксперта.

Под катом личный опыт работы в разных крупных компаниях и ответы на вопросы:

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

Итак, начнём по порядку.

По данным платформы «Авито Услуги», 23% жителей России хотели бы начать карьеру в сфере информационных технологий. Но состояться в профессии сразу же после пары курсов и стажировки не получится. Путь от студента образовательной платформы до разработчика, которого можно назвать хорошим, непростой. Мы собрали рекомендации от тех, кто добился успеха в сфере информационных технологий, чтобы помочь новичкам построить свою карьеру.

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

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

Как правильно создавать задачи?

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

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

Но как только мы касаемся основателей или руководителей высшего звена, уровень неопределенности резко повышается. Каждый рабочий день этих менеджеров состоит из самых разнообразных и быстро сменяющихся задач, которые нужно балансировать между собой буквально на ходу. Тут и внезапные созвоны, и юридические вопросы, и практическое взаимодействие с командой — все это делает роль этих управленцев совершенно непредсказуемой. Даже не смотря на наличие квартальных целей и ключевых показателей (OKR), реальной проблемой для основателей бизнеса является именно динамическая корректировка планов для решения внезапных и крайне важных задач, которых не существовало еще полчаса назад. И все это надо делать в условиях жестких временных ограничений, потому что сутки не резиновые.

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

Менеджеров проектов можно классифицировать тысячей разных способов: по опыту, по навыкам, по вовлеченности или по сфере работы. Но мы выбрали самый сложный — классифицировать по их манере управления. Один PM на всё готов и вписывает команду в любой движ, другой — напротив, отказывается от активностей и всячески оберегает «своих» от перегруза. В общей сложности мы насчитали 16 ярких типажей. Попробуем разобрать плюсы и минусы каждого.

Нас зовут Аня Ионова и Миша Дырма, мы оба уже много лет работаем в AGIMA, оба прошли путь от линейного проджекта до руководителя проектного офиса. За эти годы мы вырастили десятки РМ-ов, а общались, наверное, с сотнями, если не с тысячами. Мы поняли, что это хороший материал для — немного субъективного — обобщения. В этой статье мы описываем те типы управления, которые видели собственными глазами. А заодно — даем рекомендации, как выявить и грамотно применить скиллы каждого PM.

В 2023 году банковский сектор продемонстрировал взрывной интерес к ИИ, его применению для повышения качества предоставления финансовых услуг и совершенствования бизнес‑процессов. РСХБ также не остался в стороне. В этот период банк рассматривал возможность применения космических снимков для повышения качества залоговой деятельности и создания механизмов унификации оценки объектов залога — земельных участков, а также создание стройной системы мониторинга состояния объектов залога.

В этом материале Андрей Додолин и Паршков Александр из Департамента залогового обеспечения РСХБ вместе с Михаилом Потаниным, начальником отдела разработки «КонтролТуГоу.Ру», рассказывают о внедрении в РСХБ технологии анализа космических снимков (ТАКС) для спутникового мониторинга земельных участков и как она работает.

• Спроектировали.
• Разработали.
• Протестировали.
• Начинаем проверять работающий продукт на перформанс.
• Традиционный итог — перформанса не хватает, надо всё переделывать.

Внедрение любой корпоративной информационной системы достаточно продолжительно по срокам и требует большого объема трудозатрат [1]. В среднем необходимо около одного года на имплементацию ERP‑системы, а трудозатраты проектной команды со стороны исполнителя обычно колеблются в диапазоне 1000–3000 человеко‑дней. Объем трудозатрат фактически задает перечень тех работ, которые обязуется выполнить интегратор для заказчика. Чем больше объем выполняемых работ, тем актуальнее становится задача по их группировке для более качественного планирования, исполнения и контроля.

Именно по этой причине в [2] выделяют уровни внедрения, такие как: процессы, приложения, данные и техника, а также управление проектом и изменениями. Однако и этого деления бывает недостаточно, так как каждый уровень по прежнему остается достаточно трудоемким. По этой причине в работах [3–4] вводится понимание концепции реализации содержания проекта, заключающейся в выделении наиболее критичных областей проекта внедрения ERP‑систем, а также предложении состава и порядка выполнения работ для каждой из областей. Примерами областей служат задачи, относящиеся к анализу, проектированию, разработке, миграции, тестированию и др.

Состав работ определяется путем рассмотрения всевозможных способов, методов и подходов, позволяющих достигнуть необходимого результата с минимальными рисками задержки продуктивного старта ERP‑системы. Объем необходимых работ дает возможность увидеть плановую потребность в человеческих ресурсах, что критично для формирования ресурсного плана проекта, а состав задач обеспечивает понимание всех тонкостей реализации предстоящего проекта. В рамках текущей статьи мы рассмотрим все критичные области ERP‑проекта и суммируем способы реализации задач каждой из областей, тем самым расширяя содержание работы [4].

Как известно, у региональных разработчиков и у ИТ-специалистов есть 3 пути роста в профессии и зарплате. Первый — традиционный, это подписать контракт с работодателем и переехать в Москву или Питер. Второй — удаленка на столицы и другие крупные центры. Есть и третий путь, сегодня на HR-рынке стремительно набирает обороты новый вид выгодного для айтишников трудоустройства — аутстаффинг. Как это устроено со стороны сотрудников, какие есть плюсы (их много) и минусы (не без того) — об этом поговорим с Евгенией Забелиной, HR бизнес-партнером SSP SOFT. Тему поможет раскрыть Евгений Сомов, директор компании Софториум.

Фокус-группы, исследования целевой аудитории, оценка конкурентов — всё это не дает гарантии того, что ваш продукт действительно нужен пользователям. Это прогнозы, которые могут не сбыться. Чтобы узнать наверняка, нужно создать и выпустить на рынок минимально жизнеспособный продукт. Привет, я Артём Трубин, CPO компании ActiveCloud. В этой статье расскажу, в чем разница между PoC, MVP и MLP и как, при запуске нового продукта, снизить риски с их помощью.

Хорошо быть продактом Хабра: можно с чистой совестью получать деньги за то, что читаешь habr.com в рабочее время.

Недавно вот искал статьи про приоритизацию и удивился, что большая часть контента — это либо сравнение методов, либо опыт внедрения методов. Не подумайте, я люблю набросы в духе «лучше модели Кано ничего нет, Саб‑Зиро рядом не стоял». Но действительно ли достаточно выбрать правильный гендер и всё само собой заведётся?

Дисклеймер: теста на определение политических координат внутри статьи нет. Но есть сама система координат, которая привиделась мне после полтомика Адизеса и двух пинт.

Поспать на клиентской встрече, но с уважением? Чуть не выхватить люлей от водил‑нелегалов с Садовода, но в рамках проекта? Каждый раз мечтать уволиться, но по завершении проекта рваться на новый? Почему бы нет, если работаешь в консалтинге. Рассказываю самые яркие истории за годы своей работы в этой удивительной профессии.

Почти два года назад я написал две статьи про ремесло, в котором сам отпахал 5 лет — про консалтинг. Сначала я разобрал, как конкретно устроена эта индустрия, и что с ней стало в РФ после 2022 года. А потом препарировал основные мифы и предубеждения насчет консалтинга, чтобы вы могли лучше понять, чем конкретно занимаются эти странные молодые ребята с перманентными мешками под глазами и очень недурными зарплатами.

С тех пор меня много раз спрашивали:

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

Конечно, у меня есть такие истории, и сегодня я с радостью поведаю самые яркие, характерные и памятные из них.

Привет!

Меня зовут Андрей и я руковожу IT-подразделением. Около 5 последних лет я работаю в Яндексе с командами от единиц до сотен инженеров. Так сложилось, что команд я потрогал много и разных: некоторых руководителей от времени перемещают по частям компании и зонам ответственности и я – не исключение.

За свой не самый продолжительный, но очень интенсивный карьерный трек я увидел большое количество разных управленцев. Часть – я вырастил из своих ребят до уровней M1 и M2 (руководителей групп и служб). Часть – нанял. Часть – достались мне в наследство.

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

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

Ну что, поехали?