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

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

Когда мы молодые и амбициозные, то готовы брать все, что дают и радуемся любому повышению: «Вау, челлендж! Сейчас всем докажу! Я хочу быть руководителем, хочу власти и успеха!». На самом деле, мы не всегда понимаем, куда нас несет течение, что нас ждет на следующей ступени, на которую мы шагаем.

Я сделала короткий опрос в сообществе менторов по этой проблеме. Оказалось, что 16 из 22 менторов сталкивались с запросом «Как мне вернуться в специалисты?».

Меня зовут, Марина Перескокова, я уже 15 лет в IT, 10 из них проработала в Яндексе. У меня и моих знакомых тоже случались подобные проблемы. Давайте разберем 8 самых распространенных причин, почему руководитель больше не хочет быть руководителем.

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

Просматривая страницы на Хабре, я наткнулся на переводную статью о SAP (2020), из которой ещё была ссылка на статью из web.archive.org, бывшую когда-то тоже на Хабре (2015).

Прочтение статей мысленно перенесло меня в 2003 год.

Тогда я успешно продвигался из с состояния инженера-программиста в состояние заместителя директора по автоматизации систем управления. На рабочем месте стояла машинка под управление PTS-DOS, в которой был офис, электронные таблицы, система Гарант, браузер, аудио и видео проигрыватель. Изменение сетевых протоколов в Windows Serwer 2003 заставило достаточно быстро сменить её на более современную. Достаточно активно расширялась локальная сеть, создавались новые рабочие места.

Предприятие было автотранспортным. Начало внедряться удалённое диспетчерское управление перевозками посредством систем GPS (позднее GPS/Глонасс).

Система ERP с текстовым интерфейсом существовала тогда уже несколько лет (компания её разработчик до настоящего времени здравствует).

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

Одна из успешных разработок была создана на базе MS Access. На тот момент это была современная и удобная система для быстрой разработки баз данных и управления ими. Я сам принимал участие в её разработке, и именно она работала на нашем предприятии.

Трудно представить хоть одну современную компанию, в которой нет человека, занимающего должность с гордым названием «Менеджер». Все прекрасно знают, что менеджер – это «управленец», но кем и чем управляет продакт-менеджер? Сейчас это понятие настолько размыто, что трудно с уверенностью сказать, кто такой продакт, какие задачи перед ним стоят, и какая ответственность ложится на его плечи. 

Одним из самых важных шагов на моем пути становления продакт-менеджером было решение поступить в Школу Менеджеров Яндекса. Это шанс извлечь бесценный опыт, а также возможность получить актуальные знания и начать применять их сразу же на практике. Поступая в 2019 году в ШМЯ, думал ли я, что этот путь окажется простым? Разумеется нет. Я безусловно понимал на что иду и был полон сил и решимости, но до конца не осознавал, с какими трудностями мне придется столкнуться. На примере моего личного опыта попробуем разобраться, что же нужно для подготовки и успешного поступления в ШМЯ. Также я поделюсь с вами своей историей и дам советы, которых мне так не хватало в далеком 2019.

Итак, меня зовут Макс, и я успешно закончил Школу Менеджеров Яндекса в 2019 году, получил приглашение на стажировку и реализовал себя в качестве продакт-менеджера в «Яндекс». На словах звучит довольно просто, но через что нужно пройти, чтобы добраться до конечной цели в этом нелегком пути? 

«Не жизнь, а сказка, – сказал мне мой дедушка, наблюдая за моей удаленной работой, – разве могли мы мечтать о такой работе, трудясь от звонка до звонка на своих заводах?»

Действительно, кому-то удаленный формат работы, который предоставила нам пандемия, может показаться сказкой – но по факту 2021 стал временем больших перемен и массовых увольнений.

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

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

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

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

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

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

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

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

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

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

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

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

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

В посте я расскажу про методы повышения качества, которые сейчас получили особую популярность — построенные на основе методологий Lean Six Sigma, а также обсудим гибкие методики на основе подходов Agile и гибридных подходов PRINCE2. Разберу плюсы каждого из подхода и разберу необходимые шаги и условия для их внедрения.

Всё это в разрезе создания ПО (также подойдет и для производства радиокомпонентов).

* В статье пойдет речь о кейсе трансформации компании, чье название в этой статье нельзя упоминать. Но чтобы вы все-таки чуть лучше понимали контекст, далее в тексте я буду использовать термины "Красно-белый оператор" (КБО) и его банк (КБО Банк)

Для начала, думаю, будет нелишним начать с предыстории и предпосылках начала трансформации КБО.

Итак, в начале 2019г. КБО принимает стратегию трансформации компании в продуктовую экосистему. Что это и зачем?

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

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

«Всё, договорились, скрам-мастером теперь будет Полина», — отлично, кто-то договорился о том, что я буду скрам-мастером. Отрицание, гнев, торг, депрессия, принятие.  

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

Определение подходов к автоматизации бизнес-процессов и связанный с этим выбор конкретных технологий, особенно в крупной организации, - комплексная задача, которая требует учитывать экономические, организационные, функциональные, технические и другие аспекты. Сегодня на рынке существует множество BPM-технологий самого разного масштаба - от легковесных библиотек до крупных платформ. В этой статье мы подготовили сравнительный анализ двух очень непохожих представителей из разных областей этого спектра - Pega и Camunda. По каждой из этих технологий мы, ЛАНИТ - Би Пи Эм, накопили немалый опыт использования и наработали портфолио крупных корпоративных решений. Среди них есть проекты по автоматизации кредитных конвейеров и других бизнес-процессов в крупнейших банках РФ (Сбербанк, ВТБ, Альфа-Банк). Есть проекты как с монолитной, так и с распределенной, микросервисной архитектурой.

Если кратко, Pega - экосистема для IT-поддержки процессного подхода в бизнесе, а Camunda - набор инструментов для реализации процессных приложений.

Больше 8 лет я использую Impact Map для аналитики IT-продуктов. Я довольно активно делился знаниями об этом подходе: писал статьи, выступал на конференциях с докладами и мастер-классами, рассказывал студентам в университетах и интернам в компании. Слушатели и участники мастер-классов легко улавливают, как создавать и использовать Impact Map, т.е. с теорией нет проблем. Тем не менее, я вижу большие затруднения с применением этого подхода в реальной практике, когда нужно придумать и описать идеи для сложного IT-продукта.

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

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

Вы не одни. В сегодняшней статье Юлия Белозерова, которая выгорала уже полтора раза, решила поделиться своим опытом. Последние 10 лет она занималась управлением проектами в аутсорсинге, в продуктовых компаниях (ex-Yandex, ex-Epam, ex-Booking.com). Юля не врач, не терапевт, не психолог и не профессионал по выгоранию. Это взгляд выжившего.

Бизнес-процесс – это алгоритм действия, последовательность действий сотрудников при создании товаров, работ, услуг. Многие компании заключают договора с гражданами на оказание разного вида работ или услуг. Берут в сети готовую болванку и заключают договор, который не учитывает специфику данного вида договора. Рассмотрим простой бизнес-процесс заключения договора оказания услуг с физическим лицом, который является исполнителем, с применением нотации BPMN.