Jump to content
Калькуляторы

Подскажите курсы по управлению проектами

Вдогонку к автоматизационному круглому столу на КРОС16.

 

А посоветуйте какие-нибудь курсы по управлению программистскими проектами и бизнесанализу в контексте разработки.

 

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

Хотелось бы научиться вот чему

 

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

- оценивать сроки проектов (а соответственно бюджет). Соотносить бюджет задач с их полезностью

 

 

Короче хочется отправить ключевых заказчиков и координаторов разработчиков на какие-нибудь курсы. Чтобы люди освоили методику и реализовывали бы единый подход к ведению проектов.

 

Посоветуйте что-нибудь, пожалуйста!

Share this post


Link to post
Share on other sites

есть желание перейти от экстремального программирования к водопадной модели?

или нужны курсы по правильному agile?

Share this post


Link to post
Share on other sites

Посоветуйте что-нибудь, пожалуйста!

А которая часть нужна?

 

"Как сделать так, чтобы люди весь этот анализ делали" или "Как этот анализ делается"

 

А что касается отправить - ищем не ютубе лекции. Смотрим. Кто понравился - списываемся и спрашиваем "у вас учебный центр есть? Или, может, вас можно к нам пригласить".

Share this post


Link to post
Share on other sites

есть желание перейти от экстремального программирования к водопадной модели?

или нужны курсы по правильному agile?

 

agile - полагаю

Share this post


Link to post
Share on other sites

Посоветуйте что-нибудь, пожалуйста!

А которая часть нужна?

 

"Как сделать так, чтобы люди весь этот анализ делали" или "Как этот анализ делается"

 

 

Хороший вопрос.

 

Мне кажется что эти две части неразмыкаемые половинки одного вопроса.

 

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

 

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

 

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

 

 

А что касается отправить - ищем не ютубе лекции. Смотрим. Кто понравился - списываемся и спрашиваем "у вас учебный центр есть? Или, может, вас можно к нам пригласить".

 

А есть ли учебные центры, которые вы бы могли порекомендовать? На основании опыта :-)

Share this post


Link to post
Share on other sites

"Как сделать так, чтобы люди весь этот анализ делали" или "Как этот анализ делается"

Хороший вопрос.

Мне кажется что эти две части неразмыкаемые половинки одного вопроса.

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

 

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

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

Вот-вот.

 

 

А есть ли учебные центры, которые вы бы могли порекомендовать? На основании опыта :-)

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

 

EDIT: Уточню формулировку. Сам Левенчук систематически нечитаемый - как-то слишком заумно. Но вот ссылки он хорошие подкидывает.

Share this post


Link to post
Share on other sites

Подсмотрел в ФБ куда все зашло.

Есть у меня ощущение, что нужно кого-то на основы ITIL послать - там пусть в сторону CSI с реестром улучшений посмотрит особенно.

А из тех, что статьи и ролики в сети мне http://scrumtrek.ru/trainings/ нравятся.

Вот тут много https://www.youtube.com/channel/UCzMWFmAFm8WAjm0-q44i6WA/videos

 

Только вот у меня отношение к отправке на учёбу немного другое. Я считаю, что оно должно с другого конца идти. И не просто так что "отправьте меня куда-нибудь", а что-то вроде "мы теряем тут и тут, потому, что не хватает того и того, вот я прочитал такое и такое, теперь хотел бы с людьми-практиками на эту тему пообщаться - можно?".

Share this post


Link to post
Share on other sites

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

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

 

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

Вот этот "анализ" - он всегда и так есть, как минимум в головах разработчиков.

 

Короче, нет никаких курсов, только опыт. Ну может еще почитать других людей с большим опытом, но не местных, конечно же, тут таких нету. Например, из недавнего: https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450

 

А вообще не гоняйтесь за эффективностью разработки, это ничем хорошим не кончается. Думайте лучше о качестве.

Share this post


Link to post
Share on other sites

Есть у меня ощущение, что нужно кого-то на основы ITIL послать - там пусть в сторону CSI с реестром улучшений посмотрит особенно.

ITIL это не про разработку.

Про разработку это SWEBOK(про софт), и PMBOK(более обще). Но воспользоваться ими просто так и самому - как то нетривиально.

 

"мы теряем тут и тут, потому, что не хватает того и того".

Только частенько все это в значительной мере кажется. Это частенько выглядит как микрооптимизация кода, когда сам алгоритм тормозной.

Share this post


Link to post
Share on other sites

Есть у меня ощущение, что нужно кого-то на основы ITIL послать - там пусть в сторону CSI с реестром улучшений посмотрит особенно.

ITIL это не про разработку.

Про разработку это SWEBOK(про софт), и PMBOK(более обще). Но воспользоваться ими просто так и самому - как то нетривиально.

Я понимаю что про что - я поэтому и вставил, что основываюсь на комментах в ФБ.

А ITIL он про здравый смысл :) Он не мешал никому.

 

"мы теряем тут и тут, потому, что не хватает того и того".

Только частенько все это в значительной мере кажется. Это частенько выглядит как микрооптимизация кода, когда сам алгоритм тормозной.

Но только чтоб узнать, что есть, а что кажется, нужно во многое вляпаться.

Share this post


Link to post
Share on other sites

Мне кажется обсуждение беспредметным. Сами же пишите- "управление проектами". Сами группы участников управляться собой не будут, нужен управляющи(й/е) проектами, который должен быть над этими группами, иначе не будет управления.

Share this post


Link to post
Share on other sites

Посоветуйте что-нибудь, пожалуйста!

Для начала я бы посоветовал небольшую книжку Тома Демарко "Дедлайн".

Очень легко читается, но очень все верно написано.

 

Я думаю, это обязательно, как обязательно читать Кернигана, Ритчи, Пайка для C и Unix.

 

А далее, сам-то ты управлять проектами не будешь?

Или будешь? Лично мне кажется, по текстам на форуме, немного не твое это :). Не комфортно тебе в такой позиции.

Если не будешь - надо просто искать такого человека. Дело не простое, но не сложнее, чем искать хорошего учителя :).

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

Share this post


Link to post
Share on other sites

Подсмотрел в ФБ куда все зашло.

Есть у меня ощущение, что нужно кого-то на основы ITIL послать - там пусть в сторону CSI с реестром улучшений посмотрит особенно.

А из тех, что статьи и ролики в сети мне http://scrumtrek.ru/trainings/ нравятся.

Вот тут много https://www.youtube.com/channel/UCzMWFmAFm8WAjm0-q44i6WA/videos

 

Мы пару лет назад дернулись в этом направлении. Точнее нас пробовали дернуть - приходил умный парень, читал impact maping

Но мы тогда видимо не очень осознали неизбежности, поэтому не усвоили

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

 

Только вот у меня отношение к отправке на учёбу немного другое. Я считаю, что оно должно с другого конца идти. И не просто так что "отправьте меня куда-нибудь", а что-то вроде "мы теряем тут и тут, потому, что не хватает того и того, вот я прочитал такое и такое, теперь хотел бы с людьми-практиками на эту тему пообщаться - можно?".

 

Ну как-то так. В принципе, я готов сформулировать проблему в экономических терминах.

 

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

Share this post


Link to post
Share on other sites

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

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

 

Смотри, программист обычно слабо представляет себе бизнес-процессы, и часто еще и не очень ими интересуется. Ему говорят писать - он пишет. Это нормально.

Ворчать программист начинает, когда

- его задалбывают переделками

- недоделан один проект, а его перебрасывают на другой, потому что резко пожар

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

Share this post


Link to post
Share on other sites

Короче, нет никаких курсов, только опыт.

 

По продажам курсы есть, по бухгалтерии есть, по HR есть. А по управлению проектами - нет. Не могет такого быть.

 

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

 

Мне кажется обсуждение беспредметным. Сами же пишите- "управление проектами". Сами группы участников управляться собой не будут, нужен управляющи(й/е) проектами, который должен быть над этими группами, иначе не будет управления.

 

Управляющие проектами де факто есть. Это те, кто и так ими во всю дурь занимается.

 

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

Share this post


Link to post
Share on other sites

Надо просто искать такого человека. Дело не простое, но не сложнее, чем искать хорошего учителя :).

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

 

Кризиса на рынке труда, что-то я не наблюдаю.

 

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

 

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

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

 

Возможно стоит прийти к режиму окон. Примерно так

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

Share this post


Link to post
Share on other sites

Смотри, программист обычно слабо представляет себе бизнес-процессы, и часто еще и не очень ими интересуется. Ему говорят писать - он пишет. Это нормально.

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

 

По продажам курсы есть, по бухгалтерии есть, по HR есть. А по управлению проектами - нет. Не могет такого быть.

Кто ищет, тому всегда найдут, что продать. Только оно вообще не работает все.

Share this post


Link to post
Share on other sites

 

Возможно стоит прийти к режиму окон. Примерно так

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

это уже водопадная модель.

как я вижу, у вас в штате нет системного аналитика, либо продукт его труда игнорируется.

задача разработчика - кодирование.

на вход он должен получить функциональные требования - на выходе выдать код.

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

 

у вас есть аналитики на проектах?

Share this post


Link to post
Share on other sites

как я вижу, у вас в штате нет системного аналитика, либо продукт его труда игнорируется.

У него разработка - не основное занятие как я понимаю. Для аналитика full-time просто работы не будет. Поэтому совмещают.

Share this post


Link to post
Share on other sites

Надо просто искать такого человека. Дело не простое, но не сложнее, чем искать хорошего учителя :).

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

 

Кризиса на рынке труда, что-то я не наблюдаю.

 

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

 

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

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

Так, кого учить-то собрался? Сам учится или "стихийных" PM-ов учить?

 

Насчет варяга - отсюда не видно, что происходит, но правильный варяг не станет сразу всех учить.

Если он так поступает - не проходит испытательный срок :).

 

Но! Ты написал, что у тебя проекты "бесконечные".

ЛЮБОЕ проектное управление противоречит этому, поэтому чему бы ты не учился, кого-бы ты не взял на работу или пригласил для консультаций, тебе ничего не подойдет.

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

 

В любом случае, классика PM в виде PMBOK вам не пригодна, она слишком тяжела, и для разработки не слишком пригодна.

ITIL - это вообще о другом.

 

Вообще, я так понимаю, у вас основные задачи - постоянные модификации существующих систем.

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

Share this post


Link to post
Share on other sites

задача разработчика - кодирование.

на вход он должен получить функциональные требования - на выходе выдать код.

Это типичное непонимание разработки, не более.

Share this post


Link to post
Share on other sites

ITIL - это вообще о другом.

 

Вообще, я так понимаю, у вас основные задачи - постоянные модификации существующих систем.

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

Про постоянные модификации существующего в ITIL есть The CSI Register.

Это как раз про то, что выбирать из массы альтернатив при ограниченности ресурсов.

А потом уже как раз любой Agile - Scrum, Kanban...

Share this post


Link to post
Share on other sites

Начал читать Дедлайн Тома ДеМарко.

 

Никого не смущает подная оторванность от жизни всего происходящего?

Share this post


Link to post
Share on other sites

Начал читать Дедлайн Тома ДеМарко.

 

Никого не смущает подная оторванность от жизни всего происходящего?

Ты про роман?

 

Большие и серьезные труды по данным областям много, много дальше от жизни, чем эта сказка :).

Share this post


Link to post
Share on other sites

Начал читать Дедлайн Тома ДеМарко.

 

Никого не смущает подная оторванность от жизни всего происходящего?

Ты про роман?

 

Большие и серьезные труды по данным областям много, много дальше от жизни, чем эта сказка :).

 

Ну... когда читаешь "цель" Голдратта - всему веришь. Такое могло быть.

 

В дедлайне надуманно все :-))

 

Удивительно плохое понимание людей. Особенно для человека, который начинает роман с идеи "главное это люди".

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this