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

Профессия проджект менеджера в сфере IT

В области IT проджект работает с разными проектами и часто они имеют высокую степень изменчивости (с точки зрения хотелок клиента). Да и вообще, рыночная IT среда подвижная, в ней очень быстро возникают новейшие модели заработка. По этой причине проджект менеджер должен уметь подстраиваться под меняющиеся условия рынка, владеть нестандартными методами решения вопросов, работать командно (поскольку это является основным нашим инструментом) и уметь донести команде все изменения в позитивном ключе.
К ключевым «твердым» навыкам (hard skills) относится умение работать с совокупностью нескольких IT ресурсов, алгоритмами ИИ, знание UX дизайна. То есть это те навыки, которые можно получить через изучение, обучение и опыт, как и сам предмет проекта/клиента. А вот без гибких навыков работать намного труднее.
Поэтому проджекту тяжело обойтись без:

• Пылкого интеллекта;
• Коммуникаций;
• Способности управлять командой;
• Навыков взаимодействия с заказчиками;
• Оперативного принятия решений (порой на это отводится пара секунд).

Все банально! Расширение зоны комфорта – основа развития и освоения нового.

Выходя самостоятельно из зоны комфорта, вы попадаете в зону развития (небольшие риски и легкие усилия для освоения нового), если вас вынуждают или толкают из зоны комфорта, то вы попадаете в зону стресса.

Зону стресса характеризуется постоянной борьбой за жизнь, за выживание и сохранение достоинства. В ней нет развития и комфорта, только адаптация и попытки «уцепиться». Человек развивается в этой зоне, если он готов идти на пролом.

Зона развития не равна зоне стресса, но почти все их путают, так как они часто расширяют зону комфорта через попадание сразу в зону стресса.

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

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

Важно помнить: нужно минимизировать общение с теми, кто тянет вас в «болото».

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

#управлениепроектами #проектноеуправление #лидер #статьлидером #обучение #менеджмент #петрдикий #бизнестренер #эффективноеуправление #руководитель #руководительпроекта #дикийменеджмент

Руководители IT-проектов – весьма многогранные специалисты, на них ложится ответственность за выполнение поставленной задачи всеми сотрудниками команды. Они как «ящик с инструментами» – должны обладать широким диапазоном познаний, быть компетентными в своей сфере, но и в меру строгими.
Главная задача – проследить, чтобы проект был реализован в срок в идеальном виде, выполнен согласно оговоренных параметров и, конечно, сделан максимально качественно.

Какие хард-скиллы использовать для IT-проекта

Проект-менеджер (Project Manager) – лицо весьма неоднозначное и может работать в разнообразных направлениях в режиме многофункциональности. В первую очередь работодатели наделяют его такими полномочиями:

• контроль процесса разработки,
• курирование персонала.

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

В обязанности Project Manager (руководителя проекта) также входит формирование профессиональной команды. Для этого необходимо:

• Оценить скиллы каждого сотрудника;

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

До скорой встречи!

Стартовая страница

Документация по установке и использованию можно посмотреть (ENG): https://confluence.xpand-it.com/display/XRAYCLOUD/Coverable+issues

Далее краткое описание.

Терминология

По аналогии с сущностями (запросами) в Jira, такими как Epic (Тема), Story (История), Task (Задача), Sub-Task (Подзадача), Bug (Ошибка) и т.п. в Xray используются такие сущности как Test (Тестовое задание), Precondition (Предусловие), Test Set (Набор тестовых заданий), Test Plan (Тест-план) Test Execution (План тестирования).

Иными словами расширение/плагин Xray дает возможность оперировать новыми сущностями в рамках имеющегося бизнес-процесса. Задачи организации тестирования могут находиться как в одном проекте, на одном уровне с задачами разработки и управления, так и в отдельном проекте созданным только для тестирования.

Примечание:

Благодаря тому, что Xray использует те же сущности что и Jira при создании объектов тестирования, доступна реализация механизмов рабочих процессов.

Управление процессом тестирования происходит через контроль за переходами статусов сущностей (запросов) тестовых объектов.

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

Описание и сфера применения каждого элемента

Test (Тестовый сценарий)

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

В предыдущей публикации (Часть 1) я описывал список продуктов и их настройки, которые необходимы для работы нашей организации.

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

У нас установлен следующий формат команды разработки проекта:

• Project Manager (от 1) (не классический вариант, занимается договорной документацией на проекте, общим взаимодействием с заказчиками и ощим контролем сроков этапов);
• Аналитик (от 1 до 3) (По сути является Руководителем проекта, анализирует требования, формирует документы для разработки);
• Team lead (1);
• Программисты (от 2 до 5);
• QA (от 1 до 3);
• Дизайнер UI/UX (от 1 до 2).

 Отдельно:

• начальники секторов (общесистемные решения, прикладная разработка, тестирования);
• архитектора.

В итоге команда на проекте размером около 9-10 человек.
 

Проекты разные – долгие (больше 6 месяцев), короткие (до 6 месяцев), с чётким ТЗ и без ТЗ (накидывают новые задачи, меняют суть текущих механизмов).

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

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

Ввёл категории проектов:

• ESTIMATE - Проекты на оценке (расчёт стоимости) и сборе данных      так же вся активность до запуска в работу;

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

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

• Bitrix24
• Redmine
• Jira
• Trello
• Почта

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

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

Команда:

Руководители проектов, аналитики, начальники секторов, архитектора, тимлиды, программисты (php, SQL), дизайнеры (UI/UX), верстальщики (Front-end), тестировщики (QA).

Что нужно:

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

Для этого выбрал Jira, Confluence, GitLab (для php и js), Axure. Наличие этих систем очень хорошо упорядочивает работу, общение всех участников процесса разработки и положительно влияет на качество работы отдела и продукта.

Уточнение:

1. Считаю, что БД нужно загонять под контроль версий, но об этом в другой части;
2. Не буду в статье описывать программы для графики, презентаций или среды разработки, смысла не вижу, т.к. у каждого свои предпочтения и статья о другом.

Перечисленные плагины можно использовать вне зависимости от размера команды или процессов.

Automated Log Work for JIRA

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

Calendar for JIRA - Plan Team Activities или Mail.Ru Calendar

Календари, позволяющие настроить отображение нагрузки на каждого специалиста (написать запрос на выборку задач). Можно выбрать как группу специалистов, так и одного.

Checklist

В названии заложен смысл – чек-лист. Мы его используем для заведения мелких задач в общей задаче или для создания списка каких либо пунктов после их выполнения «чекаем» (отмечаем как выполненное). У каждой такой задачи можно проставить статус (статусы можно настроить в панели управления плагином). В такой список попадают задачи, где название задачи есть её описание, т.е. не требует большого описания и дополнительных данных.

GitLab Listener

Удобный плагин для интеграции GitLab с Jira. Даёт возможность не выходя из проекта увидеть активность, проблемы при коммитах (и других командах), просмотреть комментарии и всю историю по проекту.