👋🏻Привет! Сегодня понедельник, а значит, старт новой тематической недели! Меня зовут Даша (@Daria_linlin) и я запускаю образовательные продукты.
Последние 3 года я работаю исключительно в EdTech стартапах, таких как Skyeng, ComicsSchool, а также являюсь членом замечательной команды Qmarketing. Кроме того, я начала нашу движуху с Girls Do IT!🦸🏻♀️
Всю неделю я буду делиться с вами знаниями о project management в IT. Вместе мы разберем:
➖Что это такое и в чем отличие от классического project management?
➖Какие фреймворки существуют в PM?
➖Что такое Scrum и с чем его едят?
➖Как правильно ставить ТЗ (техническое задание)?
➖Разберемся в многообразии таск-трекеров.
Я буду рада ответить на ваши вопросы, поэтому не стесняйтесь их задавать!
#тематическаянеделя_project
Последние 3 года я работаю исключительно в EdTech стартапах, таких как Skyeng, ComicsSchool, а также являюсь членом замечательной команды Qmarketing. Кроме того, я начала нашу движуху с Girls Do IT!🦸🏻♀️
Всю неделю я буду делиться с вами знаниями о project management в IT. Вместе мы разберем:
➖Что это такое и в чем отличие от классического project management?
➖Какие фреймворки существуют в PM?
➖Что такое Scrum и с чем его едят?
➖Как правильно ставить ТЗ (техническое задание)?
➖Разберемся в многообразии таск-трекеров.
Я буду рада ответить на ваши вопросы, поэтому не стесняйтесь их задавать!
#тематическаянеделя_project
В чем особенность project management в IT?
Для начала давайте определимся, что означает менеджмент проекта. Менеджмент проекта — это процесс организации работы команды таким образом, чтобы была достигнута цель и задачи проекта в ограниченное для него время. Проще говоря, вам нужно любыми средствами сделать проект, не профакапив дедлайн.
Звучит просто! На деле все сложнее — для достижения результата надо общаться практически со всеми структурами компании и нести ответственность за результат.
Важно понимать, что роль менеджера проекта не равна роли менеджера продукта (в СНГ их любят смешивать). Проджект — это про сделать в срок без выходящих за пределы бюджета трат. Продакт — это про ответственность за сам продукт и его прибыль (продуктом является любой источник ценности для клиента). У проджекта может быть несколько проектов, в которых задействованы разные продукты компании.
В чем отличие проджекта в IT от классического менеджмента проектов (например, в консалтинге)?
1️⃣ высокий уровень неопределенности при разработке (поэтому в IT зачастую используется Agile методология);
2️⃣понимание цикла разработки продукта (SDLC) (при этом специфика работы отличается от того, над каким продуктом вы работаете, так gamedev и e-com требуют разных подходов);
3️⃣умение общаться с разработчиками, понимание технического языка и специфики (чтобы корректно ставить ТЗ, приоритизировать и оценивать необходимое количество часов на выполнение задачи).
Отвечая на любимый всеми вопрос «как стать менеджером проектов?», я хочу порекомендовать информативную статью по ссылке ниже:
https://vc.ru/hr/99129-hochu-stat-pm-om-v-it-chto-delat
Продолжение темы ждите завтра :)
#тематическаянеделя_project
#лонгрид #карьера_в_IT
Для начала давайте определимся, что означает менеджмент проекта. Менеджмент проекта — это процесс организации работы команды таким образом, чтобы была достигнута цель и задачи проекта в ограниченное для него время. Проще говоря, вам нужно любыми средствами сделать проект, не профакапив дедлайн.
Звучит просто! На деле все сложнее — для достижения результата надо общаться практически со всеми структурами компании и нести ответственность за результат.
Важно понимать, что роль менеджера проекта не равна роли менеджера продукта (в СНГ их любят смешивать). Проджект — это про сделать в срок без выходящих за пределы бюджета трат. Продакт — это про ответственность за сам продукт и его прибыль (продуктом является любой источник ценности для клиента). У проджекта может быть несколько проектов, в которых задействованы разные продукты компании.
В чем отличие проджекта в IT от классического менеджмента проектов (например, в консалтинге)?
1️⃣ высокий уровень неопределенности при разработке (поэтому в IT зачастую используется Agile методология);
2️⃣понимание цикла разработки продукта (SDLC) (при этом специфика работы отличается от того, над каким продуктом вы работаете, так gamedev и e-com требуют разных подходов);
3️⃣умение общаться с разработчиками, понимание технического языка и специфики (чтобы корректно ставить ТЗ, приоритизировать и оценивать необходимое количество часов на выполнение задачи).
Отвечая на любимый всеми вопрос «как стать менеджером проектов?», я хочу порекомендовать информативную статью по ссылке ниже:
https://vc.ru/hr/99129-hochu-stat-pm-om-v-it-chto-delat
Продолжение темы ждите завтра :)
#тематическаянеделя_project
#лонгрид #карьера_в_IT
vc.ru
Хочу стать PM-ом в ИТ — что делать? — Карьера на vc.ru
Dilyara Saetova Карьера25.12.2019
Модели и фреймворки в project management
Условно весь процесс организации работы PM строится от выбранной в команде модели/методологии. Для удобства я поделю их на классические (традиционные) и Agile (гибкие) методы разработки.
Классические модели:
🟣Waterfall (каскадная модель)
— это последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей (нельзя вернуться назад). По данному методу все стадии и сроки проекта очень четко прописываются. Используется в основном для больших проектов с утвержденным бюджетом на расходы, которые легко предугадать (не для стартапов).
Так выглядит цикл разработки в Waterfall:
analyze➡️design➡️build➡️test➡️release
Несмотря на очевидный ➕ максимальной предсказуемости модели, она обладает существенными ➖ (поэтому ее все менее и менее используют в технологических компаниях):
➖долгий цикл от разработки до релиза и, следовательно, удаленность от рынка;
➖много бюрократии;
➖неверная оценка времени при планировании;
➖разрабатывается много ненужных фич (из-за отсутствия фидбека от пользователей/рынка);
➖очень высокая стоимость внесения изменений;
🟣PMI/PMBOK
Менее распространенный подход, который основан на документе PMBOK (свод знаний по управлению проектам).
Гибкие методологии:
🟣Lean framework
Философия разработки продукта, используемая стартапами, когда вы с наименьшими ресурсами делаете MVP (минимально жизнеспособный продукт) и уже на основании MVP-эксперимента принимаете решение о продолжении работы над продуктом.
🟣Agile
Lean mindset для разработки, когда вы минимизируете риски путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся 2-3 недели. Таким образом, после каждой итерации вы получаете ➕ фидбек от рынка, что позволяет оперативно принимать решения, не производить лишних фичей и аккуратнее тратить бюджет.
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды.
Разновидностями гибкого метода (Agile) управления являются Kanban и Scrum.
✔️Kanban
визуальный метод, использующий Канбан-доску для планирования.
Обычно доска состоит из разделов:
to do ➡️ in progress ➡️done
Здесь нет спринтов, нет специальных митингов. Данный метод позволяет лимитировать количество работы “in progress”, легче устранять “бутылочные горлышки” и наладить флоу проекта. Часто является первой ступенью к переходу на agile философию всей команды.
✔️Scrum
метод, который позволяет в жестко фиксированные и небольшие по времени итерации (sprints 1-2 недели), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определён наибольший приоритет. На сегодня это самый популярный метод в разработке
Подробнее о нем я расскажу вам завтра :)
Материалы для ознакомления:
1. Agile Manifesto
http://agilemanifesto.org/
2. книга Eric Ries “The Lean Startup”
https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898
3. Бесплатный курс от Atlassian (разработчиков Trello и Jira)
https://www.coursera.org/learn/agile-atlassian-jira
#тематическаянеделя_project
#коротко_о_главном #мир_IT
Условно весь процесс организации работы PM строится от выбранной в команде модели/методологии. Для удобства я поделю их на классические (традиционные) и Agile (гибкие) методы разработки.
Классические модели:
🟣Waterfall (каскадная модель)
— это последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей (нельзя вернуться назад). По данному методу все стадии и сроки проекта очень четко прописываются. Используется в основном для больших проектов с утвержденным бюджетом на расходы, которые легко предугадать (не для стартапов).
Так выглядит цикл разработки в Waterfall:
analyze➡️design➡️build➡️test➡️release
Несмотря на очевидный ➕ максимальной предсказуемости модели, она обладает существенными ➖ (поэтому ее все менее и менее используют в технологических компаниях):
➖долгий цикл от разработки до релиза и, следовательно, удаленность от рынка;
➖много бюрократии;
➖неверная оценка времени при планировании;
➖разрабатывается много ненужных фич (из-за отсутствия фидбека от пользователей/рынка);
➖очень высокая стоимость внесения изменений;
🟣PMI/PMBOK
Менее распространенный подход, который основан на документе PMBOK (свод знаний по управлению проектам).
Гибкие методологии:
🟣Lean framework
Философия разработки продукта, используемая стартапами, когда вы с наименьшими ресурсами делаете MVP (минимально жизнеспособный продукт) и уже на основании MVP-эксперимента принимаете решение о продолжении работы над продуктом.
🟣Agile
Lean mindset для разработки, когда вы минимизируете риски путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся 2-3 недели. Таким образом, после каждой итерации вы получаете ➕ фидбек от рынка, что позволяет оперативно принимать решения, не производить лишних фичей и аккуратнее тратить бюджет.
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды.
Разновидностями гибкого метода (Agile) управления являются Kanban и Scrum.
✔️Kanban
визуальный метод, использующий Канбан-доску для планирования.
Обычно доска состоит из разделов:
to do ➡️ in progress ➡️done
Здесь нет спринтов, нет специальных митингов. Данный метод позволяет лимитировать количество работы “in progress”, легче устранять “бутылочные горлышки” и наладить флоу проекта. Часто является первой ступенью к переходу на agile философию всей команды.
✔️Scrum
метод, который позволяет в жестко фиксированные и небольшие по времени итерации (sprints 1-2 недели), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определён наибольший приоритет. На сегодня это самый популярный метод в разработке
Подробнее о нем я расскажу вам завтра :)
Материалы для ознакомления:
1. Agile Manifesto
http://agilemanifesto.org/
2. книга Eric Ries “The Lean Startup”
https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898
3. Бесплатный курс от Atlassian (разработчиков Trello и Jira)
https://www.coursera.org/learn/agile-atlassian-jira
#тематическаянеделя_project
#коротко_о_главном #мир_IT
agilemanifesto.org
Manifesto for Agile Software Development
We are uncovering better ways of developing software
by doing it and helping others do it. These are our
values and principles.
by doing it and helping others do it. These are our
values and principles.
Scrum: инструкция по применению
Большинство компаний (не только технологических) работают по Scrum, так как это один из самых эффективных методов организации работы.
Scrum позволяет за время спринта (sprints, чаще всего от 1 до 2х недель) предоставить работающую версию/фичу и сразу получить фидбек от пользователя и скорректировать продукт во время следующего спринта (а не ждать месяцы и годы как в Waterfall).
Сам Scrum Framework состоит из
1️⃣артефактов
(product backlog, sprint backlog, sprint goal, sprint board, reports)
2️⃣ролей
(product owner, scrum master, development team, stakeholders)
3️⃣митингов (совещаний)
(sprints, sprint planning, daily stand ups, sprint review, sprint retrospective)
С артефактами все достаточно понятно, а вот какие роли есть в Scrum?
➖product owner (не тождественно менеджеру продукта!)
ответственный за product value, транслирует product vision, формирует product backlog;
➖scrum master
ответственный за эффективность команды, следит за соблюдением методологии Scrum, следит за фокусом проекта, осуществляет коммуникацию внутри команды;
➖development team
оценивают кол-во работы в спринт, оценивают что брать в разработку в спринт, могут менять sprint backlog в течение спринта;
➖stakeholders
все, кто заинтересован в успехе проекта (внутренние: менеджеры, исполнители, другие scrum команды, внешние: клиенты, партнеры, инвесторы)
В чем ➕ такой команды? Она:
➖ Кроссфункциональна
➖ Адаптивна
➖ Самоорганизующаяся
Какие бывают Scrum events (совещания) и правила их проведения?
У всех sprint meetings должен быть лимит по максимальному времени встречи, но нет лимита по минимальному (так как метод направлен на уменьшение кол-а потраченного времени на встречи).
sprint planning➡️daily standup 1/ daily standup 2/ etc.➡️sprint review➡️sprint retrospective
➖sprint planning
присутствует: вся scrum команда;
продолжительность: 4 часа для 2-недельного спринта;
цель: планирование работы в спринте;
результат: цель спринта и sprint backlog;
➖daily standup
присутствует: development team;
продолжительность: 15 минут;
цель: оценить прогресс к цели спринта, план работы на день, обнаружение блокирующих факторов и как их разрешить;
результат: план на день;
➖sprint review
присутствует: scrum команда и stakeholders;
продолжительность: 2 часа для 2-недельного спринта;
цель: оценить изменения и совместно обновить product backlog;
результат: переход к следующему sprint backlog;
➖sprint retrospective
присутствует: вся scrum команда;
продолжительность: 90 мин для 2-недельного спринта;
цель: оценка изменений самой командой, процесса работы, используемых тулзов, и взаимодействия команды в работе;
результат: проработанные вопросы добавляются в следующий sprint backlog
Прочитать можно книгу от автора методологии Scrum (но в ней только кейсы и нет теории):
https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X
А завтра я вам расскажу как правильно ставить задачи, чтобы результат соответствовал ожиданиям:)
#тематическаянеделя_project
#лонгрид #мир_IT
Большинство компаний (не только технологических) работают по Scrum, так как это один из самых эффективных методов организации работы.
Scrum позволяет за время спринта (sprints, чаще всего от 1 до 2х недель) предоставить работающую версию/фичу и сразу получить фидбек от пользователя и скорректировать продукт во время следующего спринта (а не ждать месяцы и годы как в Waterfall).
Сам Scrum Framework состоит из
1️⃣артефактов
(product backlog, sprint backlog, sprint goal, sprint board, reports)
2️⃣ролей
(product owner, scrum master, development team, stakeholders)
3️⃣митингов (совещаний)
(sprints, sprint planning, daily stand ups, sprint review, sprint retrospective)
С артефактами все достаточно понятно, а вот какие роли есть в Scrum?
➖product owner (не тождественно менеджеру продукта!)
ответственный за product value, транслирует product vision, формирует product backlog;
➖scrum master
ответственный за эффективность команды, следит за соблюдением методологии Scrum, следит за фокусом проекта, осуществляет коммуникацию внутри команды;
➖development team
оценивают кол-во работы в спринт, оценивают что брать в разработку в спринт, могут менять sprint backlog в течение спринта;
➖stakeholders
все, кто заинтересован в успехе проекта (внутренние: менеджеры, исполнители, другие scrum команды, внешние: клиенты, партнеры, инвесторы)
В чем ➕ такой команды? Она:
➖ Кроссфункциональна
➖ Адаптивна
➖ Самоорганизующаяся
Какие бывают Scrum events (совещания) и правила их проведения?
У всех sprint meetings должен быть лимит по максимальному времени встречи, но нет лимита по минимальному (так как метод направлен на уменьшение кол-а потраченного времени на встречи).
sprint planning➡️daily standup 1/ daily standup 2/ etc.➡️sprint review➡️sprint retrospective
➖sprint planning
присутствует: вся scrum команда;
продолжительность: 4 часа для 2-недельного спринта;
цель: планирование работы в спринте;
результат: цель спринта и sprint backlog;
➖daily standup
присутствует: development team;
продолжительность: 15 минут;
цель: оценить прогресс к цели спринта, план работы на день, обнаружение блокирующих факторов и как их разрешить;
результат: план на день;
➖sprint review
присутствует: scrum команда и stakeholders;
продолжительность: 2 часа для 2-недельного спринта;
цель: оценить изменения и совместно обновить product backlog;
результат: переход к следующему sprint backlog;
➖sprint retrospective
присутствует: вся scrum команда;
продолжительность: 90 мин для 2-недельного спринта;
цель: оценка изменений самой командой, процесса работы, используемых тулзов, и взаимодействия команды в работе;
результат: проработанные вопросы добавляются в следующий sprint backlog
Прочитать можно книгу от автора методологии Scrum (но в ней только кейсы и нет теории):
https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X
А завтра я вам расскажу как правильно ставить задачи, чтобы результат соответствовал ожиданиям:)
#тематическаянеделя_project
#лонгрид #мир_IT
Как правильно составить ТЗ (техническое задание)?
Сегодня мы говорим о том, как ставить задачи чтобы вас поняли :) Правильная постановка задач очень важна, ведь от нее зависит срок выполнения задачи и ее результат.
Существует множество способов/методов постановки задач, мы с вами рассмотрим сегодня только основные: User story, SMART, INVEST.
User story - способ описать то, что мы собираемся разработать и что дает функциональность для конечного юзера.
Правильная постановка юзер стори будет звучать как:
“Я как Х, Хочу сделать У, чтобы я смог Ы”
Например, я как автор, хочу написать классный пост, чтобы я смогла получить лайки:)
INVEST – метод из Agile-разработки, который построен на характеристике Product backlog, используемого в Scrum и Kanban. Задача:
I – (Independent) Независимая
N – (Negotiable) Обсуждаемая
V– (Valuable) Несет ценность для бизнеса
E – (Estimatable) Достаточно информации для оценки
S – (Small) Компактный размер
T – (Testable) Тестируемая
SMART – объективно самый популярный метод. Расшифровывается на русском обычно как задача должна быть:
S – (Specific) Конкретной (содержать полную и наглядную информацию для четкого понимания).
M – (Measurable) Измеримой (параметры для оценки ее поэтапного достижения).
A – (Achievable) Достижимой (трудной, но выполнимой).
R – (Relevant) Ориентированной на результат (как поймет, что достиг).
T – (Time-limited) Определена во времени (конечные сроки).
Например, за написанный мною пост в телеграм по теме “постановка ТЗ” я хочу получить 10 лайков за 1 день :)
Подробнее прочитать про методы SMART и User stories можно по ссылкам под постом.
#тематическаянеделя_project
#коротко_о_главном #мир_IT
Сегодня мы говорим о том, как ставить задачи чтобы вас поняли :) Правильная постановка задач очень важна, ведь от нее зависит срок выполнения задачи и ее результат.
Существует множество способов/методов постановки задач, мы с вами рассмотрим сегодня только основные: User story, SMART, INVEST.
User story - способ описать то, что мы собираемся разработать и что дает функциональность для конечного юзера.
Правильная постановка юзер стори будет звучать как:
“Я как Х, Хочу сделать У, чтобы я смог Ы”
Например, я как автор, хочу написать классный пост, чтобы я смогла получить лайки:)
INVEST – метод из Agile-разработки, который построен на характеристике Product backlog, используемого в Scrum и Kanban. Задача:
I – (Independent) Независимая
N – (Negotiable) Обсуждаемая
V– (Valuable) Несет ценность для бизнеса
E – (Estimatable) Достаточно информации для оценки
S – (Small) Компактный размер
T – (Testable) Тестируемая
SMART – объективно самый популярный метод. Расшифровывается на русском обычно как задача должна быть:
S – (Specific) Конкретной (содержать полную и наглядную информацию для четкого понимания).
M – (Measurable) Измеримой (параметры для оценки ее поэтапного достижения).
A – (Achievable) Достижимой (трудной, но выполнимой).
R – (Relevant) Ориентированной на результат (как поймет, что достиг).
T – (Time-limited) Определена во времени (конечные сроки).
Например, за написанный мною пост в телеграм по теме “постановка ТЗ” я хочу получить 10 лайков за 1 день :)
Подробнее прочитать про методы SMART и User stories можно по ссылкам под постом.
#тематическаянеделя_project
#коротко_о_главном #мир_IT
👋🏻Всем привет! Сегодня последний пост недели project management, в котором я расскажу о популярных таск-трекерах.
Их так много, что порой бывает сложно выбрать подходящий софт, понять для каких целей что лучше подходит. Надеюсь, после моего мини-гайда выбор станет легче!:) Итак...
🟣Trello
По сути это визуализированная Канбан доска, которую вы можете переименовывать как вам надо (про работу с задачами на Канбан доске я писала в постах выше:). Кроме того, это, пожалуй, самый простой и удобный таск-трекер с огромным бесплатным функционалом. Тут можно и заняться персонификацией (обои рабочего стола, стикеры на задачах, ваши аватарки), создавать отдельные доски на разные проекты/команды, добавлять людей, отмечать их, делать чек-листы внутри задач. Но все же флоу трелло не столь удобен для работы команды разработчиков (если их больше 2ух чел-к).
➕
- удобный UX
- простой в изучении
- персонификация
- полная бесплатная версия
➖
- подходит только небольшим командам
- флоу не самый удобный для большой команды разработки
- нет возможности хранить внутри артефакты проекта
- неудобно работать над большим проектом/проектами
- нет сортировки по отдельному сотруднику, только по задачам проекта
- нельзя автоматически построить анализ (напр. диаграмму Ганта)
🟣Jira
Старший брат Trello от одной компании-разработчика. Данный продукт очень популярен на рынке и используется во многих компаниях, зачастую именно в отделах разработки. Поэтому, бесплатная версия достаточно урезанная в функционале, а также сам софт требует онбординга и обучения прежде чем начать пользоваться. Однако это уже более "взрослая" версия менеджмента проекта, чем Трелло. Здесь можно группировать задачи по эпикам, отдельно отмечать категорию задач как баги, выгружать отчеты по проекту и делать запросы используя Jira Query Language (JQL).
➕
- подходит большим командам
- заточен на работу с разработкой
- есть внутренняя аналитика проекта
- удобный флоу проекта
➖
- интуитивно непонятный UX
- сложность (требует обучения)
- требует знания Agile методологии
- платный функционал
- менее визуальный
🟣Asana
Гибрид Jira:) проще в использовании и меньше заточена на разработчиков. Но опять же, не супер удобно для менеджера проекта отслеживать статус. В ней удобнее делать отдельные доски-ворспейсы для команды. Сложность в отслеживании ежедневных небольших задач.
➕
- средний уровень сложности
- подходит всем, не только разработчикам
- есть визуализация досок Канбан
- можно сортировать задачи не только по проекту, но и по юзеру
- есть различные интеграции (напр. со Slack)
➖
- трудно отслеживать проекты
- менее визуальна
- только на английском
- платная за кол-во людей
🟣Basecamp
Сильно отличается от всех предшествующих аналогов другой логикой сущностей проектов - не по канбан-доске. Какие сущности есть? HQ, отделы компании, проекты компании, внутренний чат, внутренние оповещения, встроенный календарь и хранилище документов. Также существует огромное кол-во расширений на Basecamp, где уже можно подключить Канбан-доску, различные интеграции, авто заполнение диаграммы Ганта и тд. Интересный факт, сама команда разработчиков Basecamp
- распределенная :)
➕
- средний уровень сложности
- подходит компаниям с множеством проектов и сотрудников
- можно отслеживать задачи как по проекту, так и по юзеру
- удобно работать проджекту
- визуальный
- много разрешений
- понятный UX
- можно делать объявления на всю компанию
➖
- менее удобен для команды разработки
- платный за кол-во людей
- только на английском
- нельзя персонифицировать
🟣Miro
Самый визуальный софт;) Здесь нет стандартных флоу, но зато очень удобно брейнштормить (напр. визуализировать комментарии, строить схемы). Удобство еще в том, что вы в реальном времени видите действия своей команды на доске. Из минусов, это все-таки вспомогательный софт, а также в бесплатной версии он ограничен 3 досками. И опять же - на английском :)
Надеюсь, такой краткий экскурс в project management был вам интересен:) Жду ваших комментариев и фидбека! Всем хорошей пятницы!;)
#тематическаянеделя_project #подборка #личная_эффективность
Их так много, что порой бывает сложно выбрать подходящий софт, понять для каких целей что лучше подходит. Надеюсь, после моего мини-гайда выбор станет легче!:) Итак...
🟣Trello
По сути это визуализированная Канбан доска, которую вы можете переименовывать как вам надо (про работу с задачами на Канбан доске я писала в постах выше:). Кроме того, это, пожалуй, самый простой и удобный таск-трекер с огромным бесплатным функционалом. Тут можно и заняться персонификацией (обои рабочего стола, стикеры на задачах, ваши аватарки), создавать отдельные доски на разные проекты/команды, добавлять людей, отмечать их, делать чек-листы внутри задач. Но все же флоу трелло не столь удобен для работы команды разработчиков (если их больше 2ух чел-к).
➕
- удобный UX
- простой в изучении
- персонификация
- полная бесплатная версия
➖
- подходит только небольшим командам
- флоу не самый удобный для большой команды разработки
- нет возможности хранить внутри артефакты проекта
- неудобно работать над большим проектом/проектами
- нет сортировки по отдельному сотруднику, только по задачам проекта
- нельзя автоматически построить анализ (напр. диаграмму Ганта)
🟣Jira
Старший брат Trello от одной компании-разработчика. Данный продукт очень популярен на рынке и используется во многих компаниях, зачастую именно в отделах разработки. Поэтому, бесплатная версия достаточно урезанная в функционале, а также сам софт требует онбординга и обучения прежде чем начать пользоваться. Однако это уже более "взрослая" версия менеджмента проекта, чем Трелло. Здесь можно группировать задачи по эпикам, отдельно отмечать категорию задач как баги, выгружать отчеты по проекту и делать запросы используя Jira Query Language (JQL).
➕
- подходит большим командам
- заточен на работу с разработкой
- есть внутренняя аналитика проекта
- удобный флоу проекта
➖
- интуитивно непонятный UX
- сложность (требует обучения)
- требует знания Agile методологии
- платный функционал
- менее визуальный
🟣Asana
Гибрид Jira:) проще в использовании и меньше заточена на разработчиков. Но опять же, не супер удобно для менеджера проекта отслеживать статус. В ней удобнее делать отдельные доски-ворспейсы для команды. Сложность в отслеживании ежедневных небольших задач.
➕
- средний уровень сложности
- подходит всем, не только разработчикам
- есть визуализация досок Канбан
- можно сортировать задачи не только по проекту, но и по юзеру
- есть различные интеграции (напр. со Slack)
➖
- трудно отслеживать проекты
- менее визуальна
- только на английском
- платная за кол-во людей
🟣Basecamp
Сильно отличается от всех предшествующих аналогов другой логикой сущностей проектов - не по канбан-доске. Какие сущности есть? HQ, отделы компании, проекты компании, внутренний чат, внутренние оповещения, встроенный календарь и хранилище документов. Также существует огромное кол-во расширений на Basecamp, где уже можно подключить Канбан-доску, различные интеграции, авто заполнение диаграммы Ганта и тд. Интересный факт, сама команда разработчиков Basecamp
- распределенная :)
➕
- средний уровень сложности
- подходит компаниям с множеством проектов и сотрудников
- можно отслеживать задачи как по проекту, так и по юзеру
- удобно работать проджекту
- визуальный
- много разрешений
- понятный UX
- можно делать объявления на всю компанию
➖
- менее удобен для команды разработки
- платный за кол-во людей
- только на английском
- нельзя персонифицировать
🟣Miro
Самый визуальный софт;) Здесь нет стандартных флоу, но зато очень удобно брейнштормить (напр. визуализировать комментарии, строить схемы). Удобство еще в том, что вы в реальном времени видите действия своей команды на доске. Из минусов, это все-таки вспомогательный софт, а также в бесплатной версии он ограничен 3 досками. И опять же - на английском :)
Надеюсь, такой краткий экскурс в project management был вам интересен:) Жду ваших комментариев и фидбека! Всем хорошей пятницы!;)
#тематическаянеделя_project #подборка #личная_эффективность