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

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

Привет, Хабр! Меня зовут Александр, я уже около 15 лет в IT. Долгие годы занимался разработкой, но в последнее время перешел в менеджмент.

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

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

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

Менеджер по продукту данных: специалист, который управляет информацией

Данные, если подходить к их сбору и анализу корректно, представляют собой крайне важный ресурс для любой компании. И его важность сегодня только увеличивается, поскольку большинство организаций нацелены на непрерывный рост. Создание и применение эффективной стратегии по обработке данных – значимый шаг, который предстоит выполнить менеджеру по продукту данных (Data Product Manager). Рассказываем, какие ключевые навыки требуются такому специалисту и почему эта профессия приобретает актуальность в современном ИТ-мире.

ИНТЦ – это искусственно созданные государством "научные бульоны", в которых рождаются инновации. Далее в статье будут рассмотрены ИНТЦ, а именно какие услуги они предоставляют и какую инфраструктуру дают.

Ивент шторминг (Event Storming) — это отличный способ разложить продукт по полочкам, понять, как он работает (или должен работать), а также донести это до всех участников команды, чтобы картинка в разных головах была одинаковой (что сильно упростить разработку и поможет избежать ошибок и недопониманий).

На моей практике Event Storming успешно использовался в проектировании игр, именно об этом я расскажу в данной статье.

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

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

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

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

Одним из немногих функционалов информационной системы, выносимых в отдельный подпроект внедрения, является планирование потребностей в материалах (Material Requirement Planning, далее – MRP) [1]. Существуют различные типы MRP в зависимости от вида производства и сложности планирования: планирование на основе потребления, планирование по точке перезаказа (Reorder Point, далее – ROP), сезонное планирование и др.

Простейшим видом MRP является планирование по точке перезаказа (Reorder Point - ROP). Суть ROP сводится к измерению параметров, характеризующих состояние склада: текущий уровень запаса продукции и значение точки перезаказа для неё. Если значение точки перезаказа превышает текущий уровень запаса, запускается процедура пополнения продукции за счёт внутреннего производства или закупки у внешнего поставщика (рис. 1). Внедрение ROP в стандарте ERP (Enterprise Resource Planning) пророчит сложности [2]. В частности:

Привет! Меня зовут Максим, я продакт и студент курса «Продакт-менеджер». . В этой статье я расскажу о проекте по редизайну карьерного сайта Альфа-Банка — с ним наша команда победила на хакатоне Практикума.

Проджект-менеджер - (П)
Заказчик - (З)

Стою около мольберта с красками и кисточками, готовый к работе и заряженный на успех:
(П): - Коллеги, вы сказали, что вам срочно необходима картина. Что вам нужно изобразить?
(З): - Как что? Картину.
(П): - Это понятно, что картину. Что на ней должно быть изображено?
(З): - Ну ты же занимаешься картинами, ты нам и скажи.
(П): - Эм... ну хорошо. На картине должно быть дерево?
(З): - Нет.
(П): - На картине должна быть река?
(З): - Нет.
(П): - На картине должна быть лошадь?
(З): - Ты что, дурак? При чём тут лошадь?
(П): - Но вы же не говорите конкретно, что вам нужно.
(З): - Очевидно, что никакой лошади там не должно быть.
(П): - Хорошо. На картине должен быть дом?
(З): - Да.
(П): - Отлично. Это уже хоть что-то. И какой должен быть дом?
(З): - Я понятия не имею, мне нужна картина. Может знает мой коллега.
(П): - Коллеги, какой нужен дом на картине?
(З)-2: - Что значит "какой"? Какой вы обычно рисуете?
(П): - По-разному, в зависимости от требований. Может быть деревянный, может каменный. Может быть одноэтажный, может многоэтажный. Может вообще избушка на курьих ножках.
(З)-2: - Пусть будет каменный многоэтажный.
(П): - Вы уверенны?
(З)-2: - Да я вообще не знаю, зачем нам дом на нашей картине. Нам же нужно изобразить машину.
(П): - Какую машину?
(З)-2: - Ну как, обычную спортивную машину. Коллега вам разве не сказал? А дом - это так, на фоне, незначительная деталь.
(З): - Ну да, очевидно же, что нужно было нарисовать машину.
(П): - Так а почему вы об этом сразу не сказали?
(З): - Я думала, что это и так понятно.
(П): - Хорошо. Есть какие-то требования к изображению машины?
(З): - Просто нарисуйте обычную чёрную спортивную машину.
*Рисую машину. Передаю на утверждение*
(З): - Зачем вы нарисовали двери у машины?
(П): - ???
(З): - Понятно же, что двери не нужно было рисовать.
(П): - Не бывает же машин без дверей. Зачем вам такая картина?
(З): - А это уже наше дело. Убирайте двери у машины. И круглые колёса тоже вызывают большие сомнения. И кстати, где дерево на картине?
(П): - ...

Руководители IT-проектов (РП) на рынке труда в остром дефиците: по данным hh.ru на 1 вакансию приходится 1,9 резюме. Поэтому часто в компаниях один РП ведет по 5-6 проектов. При такой загрузке успеть все и сохранить качество практически невозможно.

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

В статье Света Кыштымова, администратор проектов в Naumen, рассказала о роли администратора и задачах которые выполняет.

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

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

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

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

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

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

Что аналитик сделать для того, чтобы заинтересовать людей на проекте?

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

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