Вхід і реєстрація
Розробка · 26 листопада 2013, 14:54 2197
Андрей Барилко

Как у вас устроено управление проектами? Вопрос к программистам и ПМ

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

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

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

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

Слежение за выполнением задач, ежедневные митинги минут на 10-15. Если задача затягивается по мнению ПМ, идет разговор с программистом, выяснение причин задержки (есть ли она на само деле), отработка путей решения, консультации если программист не полностью понял предметную область или детали и нюансы задачи.

Тестеров нет, тестируем своими силами.

Вопрос: Как устроено у вас в компании? Сколько в компании (в отделе разработки работает человек)? Сколько проектов вы делаете одновременно?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: PM, project management
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Yuri Warczynski Entrepreneur, CEO в HYS Enterprise 02.12.2013 05:17

Прочитав все комменты, сложилось впечатление что:
— Ваш клиент не доволен скоростью вашей работы.
— Клиент хочет делать 10 проектов + дополнительные таски одновременно.
— Вы разделили 10 человек на две комманды.
— Вас интересует или возможно достигнуть большей скорости.

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

1. Что такое скорость? В чем бы вы ее мерили? Если вы ее повысите, сложится ли у клиента впечатление что она повысилась? Можете ли вы как то «доказать» что скорость увеличилась? Нужны ли клиенту ваши доказательства? А что же ему (клиенту) нужно?

2. Какой оптимальный размер комманды (включая прожект менеджера)?

3. Сколько проектов одновременно должна делать одна команда?

Если бы это была живая беседа, я бы сначала послушал ваши рассуждения. В этом же формате, сразу даю свое личное видение.

1. Скорость — это то впечатление которое есть у вашего клиента. Если ему кажется что вы работаете быстро — вы работаете быстро. Если ему кажется что вы работаете медленно, то вы ему обратное не докажете. Хотитие повысить свою скорость — поговорите с клиентом о том как вы могли бы повысить его прибыль. Повысите прибыль — повысится и представление о скорости.

2. Оптимальный размер команды — если мы посмотрим на количество коммуникационных «путей» (п) между членами (ч) команды, то увидим: 2ч=1п; 3ч=3п; 4ч=6п; 5ч=10п. Количество «путей» возрастает в ±2 раза при каждом увеличении команды на одного человека. Я склоняюсь к 4 (количество людей почти равно количеству путей). Похоже у вас тоже по 4 человека, но не уверен так как вы пишете что вас «около» десяти и не известно или все девелоперы.

3. По вопросу одновременных проектов — вот ссылка на слайды. Это относится и к первому пункту — ведь если проект А завершен очень рано, то он и очень рано приносит прибыль.

Відповісти
Підтримати
anonymous 27.11.2013 17:56

10 человек на 10 проектов — это, право, перебор. Вам явно не хватает людей, разве что эти проекты длятся в среднем 3-7 дней. Я вижу проблему не в управлении проектами, а в перегрузе команды «рутинным шлаком». Нужно уметь тактично послать нафиг бесперспективные проекты и сосредоточиться на 1-2 крупных (для 10 человек). Нужно научится уважать и любить себя и свою команду, запомните — всех денег не заработать, и потраченное на чепуху время не вернуть.

Відповісти
Підтримати
Андрей Барилко 27.11.2013 19:05

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

Відповісти
Підтримати
anonymous
anonymous 27.11.2013 19:19

тогда в чем проблема привлечь больше людей ? если бюджет, то тут всего два варианта ... ;)

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 19:38

Проблема бюджета. Варианты: а) отказаться от работы с заказчиком и б) отказаться от работы с заказчиком ))) так?

Відповісти
Підтримати
anonymous
anonymous 27.11.2013 19:56

проблема бюджета очевидна : a) бюджет настолько мал что не покрывает расходуемые ресурсы команды b) кто-то жмется. В любом случае налицо проблемы жадности, которые лучше осознать сразу, чем страдать от них всем вместе потом, долго и нудно ;)

P.S. «жмется» — это значит отбирает некую часть

Відповісти
Підтримати
Андрей Барилко
anonymous 27.11.2013 20:02

да ... забыл сказать, отказываться из-за бюджета — непрофессионально. нужно или запаливать изначально 10x бюджет для неинтересных проектов или уж когда «назвался груздем, то лечись дальше» ©

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 20:08

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

Відповісти
Підтримати
anonymous
John Doe 27.11.2013 20:21

Вот это уже по сути. А все это обсуждалось с заказчиком?

Відповісти
Підтримати
Андрей Барилко
anonymous 27.11.2013 20:35

Так в чем проблема так и сказать об этом заказчику — вот типа, ты добавил проекты, так и rate соответственно нужно менять. иначе он вас и дальше будет иметь, думаю, пока не сдохнете ;) если превысили, по его мнению, бюджет — так кто ему мешает найти других исполнителей, индусов там или румынов. Никто и никогда не заплатит вам больше, чем вы сами не скажете/не заявите. Не нужно боятся его «потерять» — может появится время на более значимые вещи чем вечный прогиб под этого му#ака

Відповісти
Підтримати
Андрей Барилко
Xena GL 27.11.2013 21:35

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

Я себе установила такие правила:

Правило 1 Нельзя ходить под эстимейтом заказчика, точнее, исключение: можно только в том случае, если вы с этим эстимейтом согласны.

Правило 2 Если платят почасово — то заказчик должен платить часы, опять же перед стартом очередного куска — эстимейт и эппрув в письменном виде, чтобы у него не было потом мысли, что это нигде не фиксировано и чтобы был track of record.

Правило 3 если же он платит по объему задач фиксированную цену- опять же настаиваю на том что по каждому куску скоупа должен быть мой эстимейт и просто накидываю на эстимейт 15-30% на риски,

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

Відповісти
Підтримати
Андрей Барилко
Станислав Скребцов Java Developer, Embedded Developer в Looking for a job in Kiev 27.11.2013 17:24

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

Відповісти
Підтримати
Станислав Скребцов Java Developer, Embedded Developer в Looking for a job in Kiev 27.11.2013 21:14

Ну вот — теперь вижу из новых комментариев, что я прав. Так я и думал!
Прогнулись один раз под заказчика — теперь он будет вас постоянно прогибать,
пока ваша компания не загнется!
Если весь бизнес компании завязан на одного заказчика, то компания не имеет будущего!

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

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 28.11.2013 13:32

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

Відповісти
Підтримати
Станислав Скребцов
Станислав Скребцов Java Developer, Embedded Developer в Looking for a job in Kiev 27.11.2013 21:17

В принципе, есть еще вариант — взять на работу «зубастого» PM-а, который сможет доступно объяснить заказчику, что он не прав. Но тогда вы опять же рискуете потерять заказчика и бизнес.
Так что лучше все-таки наладить продажи!

Відповісти
Підтримати
Андрей Барилко
Artur Rakytskyi Seasoned Product Manager in MilTech / AdTech 28.11.2013 14:44

Зубатому PM-у нужно платить. И у него должно быть понимание, и внутреннее убеждение того, что его работа в итоге принесет пользу всем 4 сторонам (клиенту, владельцу бизнеса, команде разработки, ему самому).
Боюсь, столкнувшись с такой бизнес-моделью, которую описал автор темы, я бы отказался по двум из этих двух критериям.

Мой совет ТС — постройте немедленно (вот прям сегодня) план выхода из кризиса вида:
1. Завершить (как можно быстрее) деятельность по текущим проектам.
2. Сделать оценку (Pros/Cons) работающей бизнес-модели, определить риски, принять стратегию их избежания/снижения влияния/устранения последствий.
3. Описать случаи (и условия их возникновения), при которых теряли/не могли получить прибыль.
4. Разработать менее рисковую, более прибыльную бизнес-модель (нанять эксперта, если своими силами не выйдет). Важно базироваться на фактах, а не мнениях, и принимать решения+сроки выполнения, а не «общую стратегию + предполагаемую ситуацию».
5. Начать новые проекты по новой бизнес-модели (если повезет, то с теми же клиентами).
6. Оценить результаты, сравнивая то что было (Pros/Cons + $) с тем что стало (Pros/Cons + $). Период сравнения рекомендую выбрать в 1 квартал, с разбивкой по месяцу (не календарному, а финансовому). По проектам в вашем случае я бы сравнение/разбивку не делал.
7. Если результат понравился, и денег стало больше, закрепить успех многократным повторением, каждый раз контролировать Pros/Cons + $, стараться не вносить больших изменений.
8. Если результат провальный, повторить с пункта 1, либо 3 (в зависимости от рисков, которые сработали).
9. Если через 3 повторения так ничего и не получилось — закрыть бизнес.

Пункт 0 — сообщить своим сотрудникам о предстоящих изменениях и их причинах, (и возможных следствиях — по желанию). Если этого не сделать, все толковые разработчики уйдут между шагами 1 и 5.

Відповісти
Підтримати
Станислав Скребцов
John Doe 28.11.2013 15:19
Пункт 0 — сообщить своим сотрудникам о предстоящих изменениях и их причинах
Пункт 0 — пообщаться с сотрудниками. Причем они сами могут очень многое рассказать. И возможно это уже было сделано.

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

Відповісти
Підтримати
Artur Rakytskyi
Artur Rakytskyi Seasoned Product Manager in MilTech / AdTech 28.11.2013 17:02
Зубатому PM-у нужно платить.
:)
Відповісти
Підтримати
John Doe
John Doe 28.11.2013 17:35

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

Відповісти
Підтримати
Artur Rakytskyi
Artur Rakytskyi Seasoned Product Manager in MilTech / AdTech 28.11.2013 18:02
9. Если через 3 повторения так ничего и не получилось — закрыть бизнес.
Затрат (времени и денег) должно хватить на это + на поддержание проектов лояльных клиентов в период перехода + на возврат средств не лояльным клиентам.
Сценарий выхода из бизнеса без долгов я, в формате DOU, рассчитывать не готов. :) Все остальные детали, и их «самая важность» зависят от того кол-ва денег и времени, которыми располагает владелец компании.
Вопрос в том, что можно сделать очень и очень многое
Я с этим не могу согласиться. Сделать можно ровно столько (или меньше), сколько есть на это средств. Или сколько владелец готов выделить, если есть и другие более важные проблемы, требующие решения в тот же период.

John Doe:

полагаю что у ТС не так много времени и средств на это.
...
Можете оценить затраты на то, что предложили?
Андрей Барилко:
я конечно понимаю что это игра, и заказчик всегда желает получить в 100 больше, чем за то что он заплатил, выжав все соки со всех

Вы часом не заказчик Андрея? :)

Відповісти
Підтримати
John Doe
John Doe 28.11.2013 18:08

Артур, перечитайте пожалуйста написанное. Было бы хорошо не смешивать в одном комментарии мои цитаты и ваши. Так же хорошо различать намеки.
Что до прямого вопроса: нет, я не заказчик, можете не устраивать «теории заговоров» — его здесь скорее всего нет.
На мой вопрос вы так и не хотите отвечать, ок. Тогда подумайте хотя бы для себя, насколько затратно все предложенное вами.

Відповісти
Підтримати
Artur Rakytskyi
Artur Rakytskyi Seasoned Product Manager in MilTech / AdTech 02.12.2013 12:44

John Doe,
Если бы я не хотел отвечать (или помогать автору темы), я бы не писал такой длинный комментарий 3 дня назад. На ваш вопрос об оценке трудозатрат у меня попросту нет ответа, и я не могу его предоставить, даже если очень захочу. Я ведь не знаю ни бизнес-моделей компании, ни проектов, ни команды, ни договоренностей с клиентами. Это все знает владелец (управляющий) компании, и мой совет адресован именно ему, а не вам, или сообществу в целом.
Мой совет — типичный план выхода из кризиса для небольшой проектно-ориентированой компании. Он основан на следующих предположениях:
— автор темы является владельцем/управляющим,
— в компании есть кризис по ряду проектов,
— в компании не ведется управление рисками,
— у компании есть запас прочности (несколько стабильных проектов, финансовый запас) для внесения планируемых изменений в бизнес-модель.
Также, мой совет основывается на предыдущем опыте участия в подобных изменениях (которые проводил не я, кстати) в IT-компаниях. Отсюда и совет производить изменения за 1 квартал.
На выполнения работ в пунктах 2, 3, 4 (и частично в 1 и 6) у меня, как PM, уходило от 2 до 5 недель, при этом я вел работу над оставшимися проектами. Но ситуация сильно отличалась от ситуации автора темы — меньше проектов, больше людей в командах разработки, другой состав команд.
Надеюсь, я ответил на просьбу.

Відповісти
Підтримати
John Doe
John Doe 27.11.2013 17:00
очень нуждаемся в вашем мнении
Простите, какой результат вы хотели бы получить?
Здесь может быть много мнений, причем основанных на опыте, и даже правильных в контексте того опыта — только у вас могут быть немного другие исходные ...
Что вас не устраивает в текущей ситуации?
Не хочу задавать наводящие вопросы и предлагать что-либо. Это не всегда имеет смысл в таком формате.
Відповісти
Підтримати
Андрей Барилко 27.11.2013 19:37

Самое главное, что не устраивает, так это давление на то, что низкая эффективность.

Відповісти
Підтримати
John Doe
John Doe 27.11.2013 19:52
какой результат вы хотели бы получить?
понятно что
не устраивает, так это давление
заказчики они такие, им вечно что-то не нравится, понятно что проблем много, и многое стоит менять, это бывает, более того, это в чем-то даже хорошо.
Что получить то хотите?
Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 19:56

Цель создания топика, убедится в том, что сам принцип ведения проектов, с учетом существующих проблем, ведется правильно, или опровергнуть этот тезис.

Відповісти
Підтримати
John Doe
Андрей Барилко 27.11.2013 19:59

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

Відповісти
Підтримати
Андрей Барилко
Xena GL 27.11.2013 21:38

он пытается вас убедить в том что вы на него должны поработать еще немножко , только бесплатно. не ведитесь на фиксед прайс. только часами и мелкими итерациями, чтобы как можно больше проплат было посредине проекта, чтобы когда подойдет время сдачи, у вас на этот момент было уже получено не меньше 60-75 процентов денег

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 28.11.2013 13:33

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

Відповісти
Підтримати
Xena GL
John Doe 27.11.2013 20:05

прямо как в анекдоте:
— мужчина, я правильно иду?
— правильно
...
причем вопрос «куда?» не поднимается

конечно хорошо, если этот топик чем-то поможет

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 20:10

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

Відповісти
Підтримати
John Doe
John Doe 28.11.2013 15:21
сделаны выводы
Поделитесь выводами и результатами, если не секрет — по мере реализации.
Відповісти
Підтримати
Андрей Барилко
св Антоний 28.11.2013 10:01
давление на то, что низкая эффективность
Да это просто у вас воспитывают чувство вины, для манипуляции.
Вы пишете, что с одной стороны боитесь потерять заказчика. Но с другой стороны — и заказчику в какой-то мере будет невыгодно с вами расстаться, поскольку и денег, по-видимому, он затратил немало, и начинать весь процесс с нуля — это дополнительные затраты. Так что, в данном случае, смело можете блефануть — мне кажется, команду не разгонят, и рейты не урежут.
Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 28.11.2013 13:34
Да это просто у вас воспитывают чувство вины, для манипуляции.
Точно в цель, спасибо.
Відповісти
Підтримати
св Антоний
Александр Труш 27.11.2013 16:58

Коментар порушує правила спільноти і видалений модераторами.

Iurii Shcherbyna Менеджер проектів 27.11.2013 15:46

Почитав комментарии понял вашу проблему и постараюсь ответить по сути.

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

1) Product Owner описывает идею. Как правило словами. Хорощо если есть хоть какие-то скетчи.

2) Product Manager создает базовую спецификацию — мокапы, юзер-стори. Все, то что PO рассказал, PM записывает, устраняет противоречия, согласовывает с текущим функционалом и описывает, какие еще изменения повлечет за собой внедрение новой фичи.

3) Product Manager описывает все это Product Owner’у.
Это итеративный процесс, но рано или поздно он завершается, ну или, по крайней мере, фичи все фичи становятся более или менее ясными.

4) Product Manager рассказывает тим-лидам какие новые фичи планируются, какие будут внедряться в ближайшее время, какие изменения нужны в старых фичах.

5) Тим-лиды могут запросить время на инвестигейшн и пригласить ключевых разработчиков, а могут сразу рассказать, какие измения в коде это повлечет. PO это по барабану, а вот PM стоит послушать. Ну, и, понятно, тим-лиды должны быть в курсе, что желают другие команды. Смены интерфейсов и бизнес-логики касаются всех.

6) Рисуется дизайн.

7) Обсуждается дизайн в том же составе, что и в пункте 5. Опять же прошло время и у PO может измениться видение фичи. Тим-лиды могут додумать какие-то важные технические моменты и риски. PM это все фиксирует, придумывает как риски минимизировать.

8) По результатам уже есть вменяемая документация, на которую тестировщики начинают писть тест-кейсы.

9) Программисты пишут код. Подразумевается, что сначала пишутся юнит-тесты, потом реализуется бизнес-логика.

10) Важно: программистам нужно общаться с тестировщиками и читать тест-кейсы. PM должен тоже общаться со всеми: читать кейсы, слушать стендапы. Он, на данном этапе, такая себе служба раннего оповещения. Может заметить, что что-то неописано тест-кейсами или какой-то кейс пропущен программистами. Может увидеть, что несмотря ни на что фича была понята не правильно и кто-то что-то не то пишет...

11) Код-ревью. Хорошо, когда оно групповое. Формат может выбрать сама команда. У меня было одновременно в двух командах по-разному. Одни просматривали в специальной тулзе код, другие устраивали демо кода. Можно и чтобы тим-лид (ключевой разработчик) в одиночку смотрел, но мне такой поход кажется не очень продуктивным.

12) Разработчики проводят демо3 функционала. По завершении таски: PM-у, еженедельно — для PO. Тестировщки обязательно присутствуют на демо для PO. Да и вообще всем заинтересованным стоит там присутствовать. По моему мнению каждый должен сам показывать что он сделал. Получается более подробно, растет уровень ответственности, прокачивается английский.

13) Фича или набор фич передается на тестирование, запускаются автотесты по старому функционалу.

14) Фиксятся баги.

15) Проводится регрешн на тестовом окружении.

16) Проводится регрешн на стейбл.

17) В некоторых схемах релиза ели есть пре-релизное окружение — проводится регрешн на нем.

18) Релиз.

19) Смоук-тестирование продакшна.

20) Принятие решения все ли хорошо на продакшене или нужно делать откат.

21) Регрешн на продакшне.

22) Хотфикс на продакшн.

23) Написание автотестов на только что реализованный функционал.

За кадром остались стандартные скрамовские процессы — эстимации, скрамы, ретро. Они есть.

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

Відповісти
Підтримати
Iurii Shcherbyna Менеджер проектів 27.11.2013 16:44

Эх, после того лайкнули, нельзя поправить опечатки :(

Відповісти
Підтримати
Iurii Shcherbyna
Sergii Voloshyn Product Manager в DOU.ua 27.11.2013 16:46

Редактирование исчезает через 30 минут после публикации.

Відповісти
Підтримати
Iurii Shcherbyna
Iurii Shcherbyna Менеджер проектів 27.11.2013 16:55

Эх, значит так и останется теперь :( Впредь буду внимательнее писать. Странно, что хром у меня на ДОУ ничего не подчеркивает. На других сайтах — ок.

Відповісти
Підтримати
Sergii Voloshyn
Sergii Voloshyn Product Manager в DOU.ua 27.11.2013 17:11

Я немного отредактировал, чтобы комментарий легче читался.

Відповісти
Підтримати
Iurii Shcherbyna
Андрей Барилко 27.11.2013 19:42

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

Відповісти
Підтримати
Iurii Shcherbyna
Andrew Kovalenko Team Lead в Jaybird Group 27.11.2013 13:42

Добрый день. Согласно Вашим реалиям, я бы предложил дать больше воли и инициативы разработчикам. Пускай сами определяют приоритетов своих тасков. Но давайте им всю необходимую информацию, чтобы у них не было проблем с пониманием приоритетов. Постарайтесь уменьшить количество проектов (возможно заморозить). Вы увидите как производительность разработчиков увеличится. В этом случае роль менеджера будет в своевременном, полном информировании программистов.
Это то, что могу предложить. Может все слишком прозрачно и сурово, но это немного поможет. В мультипроектной среде скрам может быть только избыточным. Мы вот стараемся находить наиболее подходящие методы менеджмента в каждой исключительной ситуации. Проблем хватает. Каждая компания уникальна и каждый может предложить свои практические методологии менеджмента. Подбирайте себе сами, эксперементируйте и находите то, что Вам больше подходит. Если Вы думаете, что не сможете найти, то ошибаетесь.
Спасибо за возможность дать совет.
—
Андрей, Team Lead

Відповісти
Підтримати
Андрей Барилко 27.11.2013 13:58

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

Відповісти
Підтримати
Andrew Kovalenko
Andrew Kovalenko Team Lead в Jaybird Group 27.11.2013 14:09

В вашем случае получается проблема у клиента. Думаю, стоит искать решение проблемы клиента. Его может и устраивает то, как сейчас идет работа. Но показав ему вариант с уменьшением количества проектов и с увеличением производительности Вы просто дадите ему еще один вариант для выбора. Думаю он не будет огорчен. И я точно уверен, что для клиента важность у всех проектов разная.
Андрей, Team Lead

Відповісти
Підтримати
Андрей Барилко
Alex Polunin QA Team Lead в ZONE3000 27.11.2013 12:45

Добрый день!
Наймите 1 Junior PM or Junior Tester. В помощь Вашему менеджеру. Вешаете на него 2 задачи. Time managment and QA.
Думаю сработает.
Я в данный момент именно такой работой и занимаюсь. Правда команда 7 чел. и проект 1-2.

Відповісти
Підтримати
Андрей Барилко 27.11.2013 13:18

Спасибо Александр, сейчас подумаю над этим.

Відповісти
Підтримати
Alex Polunin
Beaver Green 26.11.2013 16:43

В компании сотни человек и десятки проектов. Как правило один человек работает на одном проекте (но может помочь на другом если надо).
Методики разработки на разных проектах разные. От «ковбой-кодинга» и «управляемого хаоса» через Agile и до ватерфольных RUP и CMMI. Наиболее популярен скрам в командах около 10 человек.
Чем Вам будет полезен такой ответ?
Думаю что для компании где на «10 проектов по статистике 9 ребят» любые советы от «нормальных» ИТ компаний мало полезны.

Відповісти
Підтримати
Андрей Барилко 26.11.2013 17:52

Очень полезен, для сравнения и понимания.
Мы ближе к Scrum. У нас около 10 проектов, но мы разделили коллектив на 2 группы, под управлением PM. Пока проекты согласовываются (у нас это долгая процедура) и идет постановка задач на одном из проектов, мы выполняем другую группу задач на другом проекте, итого нет простоя, постоянное движение. Из негативного, что проекты двигаются не сильно быстро, и бывает скопление большого кол-ва задач, а так же если найдены баги, программистам требуется возвращаться к прежнему проекту и править баги.

Відповісти
Підтримати
Beaver Green
Alexander T 26.11.2013 19:32

ИМХО из негативного, что людей бросают туда-сюда. Между тремя проектами я помню еще как-то переключался, а если между 10 ? Это ж ужас.

Відповісти
Підтримати
Андрей Барилко
Pavel Kruchina CTO 26.11.2013 20:46
Из негативного, что проекты двигаются не сильно быстро, и бывает скопление большого кол-ва задач
А в остальном, прекрасная маркиза, всё хорошо, всё хорошо...
Відповісти
Підтримати
Андрей Барилко
Летикова Ирина FrontEnd Developer 27.11.2013 13:07

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

у нас большие проекты и большие команды, и каждый занимается своим — есть программисты, верстальшики, дизайнеры, тестировщики и ПМы

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 13:13

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

Відповісти
Підтримати
Летикова Ирина
св Антоний 27.11.2013 13:26

Либо заказчик, либо руководство хитросделанные. Это так что-ли получется, мол, заказчик платит за один проект, а в нагрузку еще пару проектов просит беспатно?
Очень кажется, что если разработчик делает больше, чем один проект — то его по деньгам обманывают больше, чем в 2 раза :)

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 13:38

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

Відповісти
Підтримати
св Антоний
Андрей Барилко 27.11.2013 20:00

Спасибо Александр, очень полезный материал.

Відповісти
Підтримати
Alexander Shapoval
Євген Козлов Front-end developer в SoftServe 27.11.2013 21:43

не сразу нашел. уже описывали такое на Хабре:
habrahabr.ru/post/147276
habrahabr.ru/post/197684

Відповісти
Підтримати
Alexander Shapoval
св Антоний 28.11.2013 09:57
но заказчик считает что эффективность низкая
Это — очень абстрактно. Нет запланированного экономического эффекта, или в чем тут дело?
Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 28.11.2013 13:36

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

Відповісти
Підтримати
св Антоний
Iurii Shcherbyna Менеджер проектів 26.11.2013 16:16

Все зависит от специфики проектов.
И процессы надо строить исходя из специфики проекта, а не компании в целом.

Для сайта визитки тестировщик не нужен.
Для проекта в котором тонны статистики, разнооборазные выборки и активная разработка не прекращается уже 10 лет — они нужны обязательно.
А еще автоматизация тестирования, поддержка спек и тому подобное.

Відповісти
Підтримати
Андрей Барилко 26.11.2013 17:56

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

Відповісти
Підтримати
Iurii Shcherbyna
John Doe 27.11.2013 17:13
Но суть вопроса именно в том, рассмотреть модели работы, сравнить их, насколько это возможно, на разных проектах и компаниях.
возможно суть запроса в том, что бы найти рабочую и подходящую вам сейчас и в будущем модель (методологию) командной работы и управления?..
Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 26.11.2013 17:58

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

Відповісти
Підтримати
Iurii Shcherbyna
Alexander T 26.11.2013 19:35

Знавал я одного заказчика. Приехал к нам в Донецк, повел нас в ресторан :) Рассчитываясь выкинул из кармана сотни, двухсотки — спрашивает этого хватит ? Ну как к деньгам относился, так и ко всей Украине. Обидно даж как-то стало. Тоже на тесты жмотился. Потом правда взяли одного человека, отдача сразу сильная пошла.
Вы хоть тесты пишете ?

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 13:07

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

Відповісти
Підтримати
Alexander T
Alexander T 27.11.2013 13:10

Ну наш потом переменил мнение о тестах и тестерах

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 13:16

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

Відповісти
Підтримати
Alexander T
Iurii Shcherbyna Менеджер проектів 27.11.2013 14:42

Странно это звучит.
Заказчик должен получать фичи стабильного качества вопределенные сроки.
В эти сроки вы включаете и написание тестов.

Если и вы и заказчик заинтересованы в стабильности продукта, то без тестов — никуда.

Відповісти
Підтримати
Андрей Барилко
Андрей Барилко 27.11.2013 20:12

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

Відповісти
Підтримати
Iurii Shcherbyna

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.