×

Как быстро и больно убить проект

В начале хотелось бы представиться с профессиональной стороны: я не являюсь супер-мега гуру проектного менеджмента, но постоянно сталкиваюсь с проблемами и ищу их наиболее выгодное решение. Для этого я использую свой опыт и те размышления, которые возникают во время чтения всевозможной литературы по управлению процессами/проектами/людьми. И конечно же, я прислушиваюсь к мнению окружающих, но только как еще к одному источнику информации. Итак, я — РМ/ScrumMaster, а в недалеком прошлом QA.

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

Итак, 10 рекомендаций, как быстро и больно убить проект:

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

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

3. Оценивать время выполнения проекта или задачи нужно очень оптимистично, и конечно же, вычитать менеджерские 20%. Ведь менеджерам всегда всё нужно как можно скорее. Самая оптимистичная оценка позволит сократить время разработки и поможет вложиться в сроки.

4. Забудьте слова Scrum, XP, Kanban и всё, что связано с процессами. Настоящие профессионалы действуют по наитию и всегда помнят всё, что происходит вокруг и — что самое главное — контролируют это.

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

6. Совершенно ненужным элементом разработки является тестирование. Избавьтесь от него и не забудьте уволить специалистов-куашников. Знать, что с продуктом что-то не так — не нужно: с ним ведь ничего не может приключиться. И, самое главное, мы создаем функционал, а не баги.

7. Не стоит поощрять желание к саморазвитию. Это приведет только к потере времени, денег и нигде больше не пригодиться. Более того, ваша команда получит новые скиллы, попросит повышения оплаты или просто пойдет применять их в другом проекте. Ваше собственное саморазвитие и, тем более, команды — пустая трата ресурсов. Лучше сказать клиенту, что возможна скидка на создание продукта, так как разработчики все еще из прошлого века.

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

9. Избавьтесь от зон отдыха и не вздумайте поставить настольный теннис или футбол. Это дорого, шумно и только отвлекает всех от выполнения поставленных задач. Люди лучше работают без отдыха и разрядки, а после 18:00 у них полно своего личного времени.

10. Обязательно жестко контролируйте время: как прихода/ухода на рабочее место, так и на выполнение задач. Это привнесет прозрачность в рабочие процессы, даст возможность все предусматривать и контролировать.

А как вы убивайте свои проекты? :)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




Найкращі коментарі пропустити

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

А ещё ЗП задерживайте и никаких бонусов. А то ещё работники подумают, что они за деньги работают

Не увольняйте менеджера, трём оставшимся будет скучно играть в преферанс.

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

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

Если же в случае успешного завершения проекта/итерации, будет значительное поощрение (а не тортик) всех участников, то люди сами организуются без этих ваших 500 страничных талмудов кто перед кем первым должен кепку снимать.

117 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Если бы каждому умному менеджеру плюсующему эти 10 пунктов дать задачу составить метрики и определить влияние каждого пункта на эффективность выполнения работы, я более чем уверен, в результате своего анализа каждый бы поменял своё мнение в корне.

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

Плюшки и прочая ерунда не более чем наживка для найма. Если в компании не поставлен процесс, то ничего не поможет. А если поставлен, то люди эффективно работают и с вашими 10 пунктами.

Спасибо ТС за тему, которую всегда полезно осмыслить. Из личного:

1. Рыба гниет с головы. Если инвесторы, СТО, СЕО и другие O вместе с PM не понимают в айти, проект умрет, даже при выполнении всех пунктов.

2. Больше одной нано-технологии в проекте, заставит его сильно болеть детскими болезнями, и в конце концов если не убъет, то превратит в генетического монстра не способного к полноценному существованию.

3. Срам ради срама, без понимания зачем это все и в какой момент, он нужен. Превратит проект в четкое выполнение спринтов, без разработки самого проекта, когда на бюрократию тратится 90% времени, а на разработку оставшиеся 10. Обычно не хватает денег разрабатывать с такой скоростью.

4. Развитие от частного к общему. Сначала фичи для заказчика, а потом попытка их все связать в единый продукт приведет к тому, что заказчик не сможет понять, зачем Вам 3 месяца на приведение в порядок, того, что было сделано за 3 недели.(Хотя это имеет отношение к п.1)

5. Частый рефакторинг. Как говорят: «лучшее враг хорошему». Нельзя устраивать поединки между разрабами по код ревью. Обычно в таком случае код превращается в полное гуано.

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

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

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

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

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

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

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

автор одной ногой может быть стоит или бывал когда-то в менеджменте. своими собственными ресурсами никогда не управлял — 100500%. Статья больше похожа на слабенькую попытку лёгкого троллинга собственного руководства.

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

Думаю что эти пункты не только в ИТ применимы))

Мне кажется для убийства проекта будет достаточно 4 пункта.

мене на проекті вбив пункт 10 :)

эммм... это вроде как каждый джун знает...

знать — не значит применять к проекту... уж поверьте)

Написание вряд ли чтото поменяет

А ещё ЗП задерживайте и никаких бонусов. А то ещё работники подумают, что они за деньги работают

как хорошо, что я никогда с таким не сталкивался

у меня так проект умер

у моего проекта так брат умер!

Якщо менеджер не був тривалий час розробником або тестувальником — він ніколи не буде адекватно дивитись на проект, на дати і на слова розробників. Якщо команда не може відкрито послать менеджера — то вони будуть посилать проект.

Что значит послать менеджера, а когда вы провалите проект — вы встанете и скажете, беру всю ответственность на себя.. я завалил сроки... менеджер не виноват... ? Обычно все почему-то молчат.... У каждого в проект своя роля и зона ответственности и слаженная работа всех приводит к успеху проекта...

Для того, щоб провалити проект потрібен час — якщо менеджер не вкурсі справ дева на проекті, то не потрібно кивати на нього. Дев не завалив проект — він виконав його вчасно, просто менеджер на «верх» відрапортував, що дев зробить його раніше, при цьому думкою дева знехтував. Так, у кожного своя роль і зона відповідальності, але менеджер несе відповідальніть за показники проекту, а не деви. Частіше менеджер мішає проекту, ніж йому допомагає. Під «послати», я мав на увазі, що менеджер готовий до того, що команда може сказать йому, що сроки чи вимоги по проекту це фігня і не відповідають дійсності і менеджер прислухається до команди... Частіше виходить навпаки — менеджер прожимає команду, думаючи що вони ліняться, і команда посилає проект.... Команда замовчує проблеми або ідеалізує ситуацію на проекті, поки на проекті не буде аврал.
Менеджер має виступати в ролі людини, яка порве любого за свою команду, незважаючи чи то начальство чи менеджер іншої команди. В реальності ж, багато бла-бла від компанії, менеджера — команда це відчуває і в неї пропадає мотивація працювати.... Тим більше нести відповідальніть за проект...

Тут важливо тримати баланс між замовником і командою, а не просто «рвати» за свою команду, ситуації бувають різні, відповідно і твердження відносне

Коли це зовнішній замовник — то так, але я коли говорив — я мав на увазі внутрішнього замовника. І тут навіть не суть в тому, хто замовник — в реальності причини ставити нереальні сроки можуть бути зовсім інші. Хтось захотів «зарісоватся» перед начальством чи перед іншим менеджером, хтось планує відпустку на той час і т.д. Тобто це винятково особистісні речі... Але так, як у нас «менеджери» із пару роками досвіду, вже вважають себе царями і богами — то і виходить така ситуація. Всі «менеджери», але нема майже жодного «керівника». ru-management.livejournal.com/236915.html
Не знаю, як там в компаніях з Європи чи США, але в нас я не бачив жодної компанії, де у вакансії було написано, що кандидат йде працювати до конкретної людини в команду. І кандидат вибирає цю компанію, не через зп, плюшки, а через можливість робити в саме ці команді. Тобто компанії відрізняються одна від одної, тільки дизайнерським ремонтом, парой сотнею баксів і тенісним столом. Але, не позиціонують себе, як компаніїї, в яких працюють професіонали із відомими іменами. Звісно є винятки — чим меньша компанія, тим там більше цінять людей і дослухаються до їх думок. Але оскільки ринок роблять великі компанії, то про інших ми не чуємо і не здогадуємось. Хочеться грошей — треба йти у велику компанію і працювати за чистий кеш, а не за дизайнерський ремонт. Хочеться адекватного менеджменту — йти у невелику компанію, де власник чи перша особа обідає із підлеглими на кухні і між вами немає ще 5 менеджерів.

Много менеджеров и никакого менеджмента.

Стреляю по менеджерам из рогатки, Тогда они перестают придумывать тупые, никому (кроме них на 5 секунд) не нужные прожекты, и идут заниматься полезными делами (например не задрачивать меня) ))
Если серьезно, Мне все равно на мнение менеджера, я сам ставлю сроки выполнения, удобные мне, и предупреждаю о +/- 10 днях (мало ли, больничный). Если сроки не устраивают — лесом.
А мое личное время, только мое — кто тронет, того не найдут...)))

Мне жаль что не работали с хорошими менеджерами, а ваш подход очень «правильный».

Мне все равно на мнение менеджера, я сам ставлю сроки выполнения, удобные мне, и предупреждаю о +/- 10 днях (мало ли, больничный). Если сроки не устраивают — лесом.
Отличный способ убить проект :-).
Весьма распространенный кстати.
Но ТС вроде спрашивал, как менеджеру это сделать, а не исполнителю.

я бы даже сказал — убить его в зародыше (читай — pre-sale стадия)

конечно же. обычно наличие ПМа ведет к фейлу проекта в 99.99%.

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

Но прежде все-таки манагеры убьют программера. И делать они это будут примерно так:

Если сроки не устраивают — лесом.

Если лесом — то без зарплаты
И все становится на свои места.
.
Програмер-то работу себе легко найдет,
Ой не всегда так есть, и не всегда так будет.
Как самый «близкий» пример — смотрим тенденцию.
igate.com.ua/...ichestvo-it-spetsialistov
Конечно не то, что «количество вакансий растет», а то, как изменяется отношение «количество вакансий/количество откликов». (Последний из графиков)
Экстраполируем. Делаем выводы.
Самое грустное интересное заключается в том, что аналогичные графики я видел и по США, и по Европе. И даже по количеству проектов/количеству фрилансерах на соответствующих биржах.
Так что не все так радужно.
P.S. Специально для специалистов по «интеллектуальному анализу данных» :-). Вот в этой области ситуация — по крайней мере в мире и Европе — строго обратная. Думаю, скоро это докатиться и до нас.

Читал пост — и был согласен (почти) со всем. И тут на тебе

манагеры первые под нож пойдут.
Имеется ввиду «нож» сокращения или «нож» устроителей маски-шоу?
Если первое — то должен не согласиться. Как представить себе проект (более менее серьезный, не стартап на три Васи с Петей и не «бухгалтеру формочку новую склепать по быстрячку) без РМ?
Если второе — то там от позиции в проекте позиция в ....., ну в общем в процессе «дознания» ....... особо роли не играет. Более того, исходя из того, что РМ в силу свой профессии, как правило, более готов к психологической обороне и умеет «держать удар», пресовать («под нож») в первою очередь будут как раз девелоперов-интравертов.
Впрочем, это тема совершенно другого топика.
Упадут зарплаты и толпа вайти-вайти резко поуменьшится.
Поуменьшится хороших специалистов, которые не хотят работать с футболистами, чаеглотами и просто обоятельными общительными людьми, для которых проект без этих плюх — «завалится», а их же эстимейты контроль сроков выполнения задач — страшный ужас :) Останется толпа ничего неделающих хомяков, для которых и понадобится ПМ — который качественно налапшит всем :)

Работу все себе найдут. А вот зарплату...

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

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

О, снова статистика :) Один раз на вопрос об источнике и репрезентативности выборки меня высмеяли, мол я не умею в гугле строить запросы с несколькими уровнями вложенности. Куда сейчас отправите? :)

Ну а мой личный опыт говорит иное. Вот такая незадача...

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

американские в 20%.
То вы, кстати, с французскими не работали.
3 из 3 проектов вытащены исключительно благодаря наличию здесь своего PM, работавшего прокладкой и нивелировавшего их идиотизм. Но там и проекты были маленькие, по паре человеколет.

А примеры «серьезных проектов» и «команд» можно в студию? :) Если программист говорит два дня на разработку — значит два дня на разработку, особенно если он гарантирует и дает результат. Если есть другой программист — который точно также даст качественный результат за меньший сроки можете смело нанять его. Хорошая «Команда» это в первую очередь набор специалистов которые, каждый по отдельности дает, дает качественный результат в нужные сроки (а таких людей поверьте мне минимум, в основном все футболисты и абстракционисты). И если эти сроки не нравятся заказчику и Пму в частности — они как сказал автор сообщения — идут лесом. И может быть это «завалит проект», но завалится не из-за этих специалистов, а из-за того что кто-то согласился и взял на себя ответственность сделать что-то в сроки или суммы и не может найти (если мягко комментировать этот бессмысленный поступок желающего наживы посредника) людей, которые могут это с делать :)

Он хоть что-то дает :) в отличии от тех кто в офис ходит чаи и футбол гонять :)))

А примеры «серьезных проектов» и «команд» можно в студию?
Ну например: ~70 человеко-лет на текущий момент (работа в разгаре), рост команды от 1 до 18 человек в течение 8 лет, проект продолжается на стадии деплойментов и расширения клиентской базы — и постоянная [до/пере]работка по меняющимся требованиям в режиме перманентного раша.
Такой пример устроит?
Дальнейший неструктурированный поток мысли комментировать сложно, попробуйте натянуть его на мой пример самостоятельно :)

Upd. да, и из команды НЕ 2-3 чепловека пишут проект, а все. То я про другой Ваш опус — улыбнуло, спасибо :)

Дальнейший неструктурированный поток мысли комментировать сложно,
Так вы структурируйте свои мысли, чтобы не приходилось ничего «натягивать».
улыбнуло, спасибо
Рад что в условиях вашего «перманентного раша» вы улыбаетесь :)
с небольшими задачками на одного человека
 Я вам так скажу: я делал много проектов и в больших и маленьких (по мерках скрама) командах, и управлял и мной управляли, по разному. И могу гарантированно сказать, что любая большая задача разбивается на подзадачи, а огромный проект на подпроекты с отдельными командами. И везде для создания качественного ПО надо этот самый «фрилансер» (давайте его так называть) — человек который гарантировано сделает, то что сказал в сроки на которые ОН согласился, а работа ПМа/СМа сводится к качественному описанию задач и красивой группировке графиков по их выполнению а также отстранения бизнеса от рабочего класса. А этот подход не подходит "
команде и компаниям с серьезными проектами
" в первую очередь потому, что у них будет «команда» из 15 например человек, из которых проект напишет все равно 2-3 человека — остальные будут для красоты.. а почему так? а потому что сложно сказать/доказать заказчику что нормальный производительный прогер стоит 5-6к зелени в месяц — никому такой аутсорс не надо ) Зато легко сказать что мы наймем «команду» с синьеров по 2-3к в среднем и все они так важны и трудолюбивы и без них никуда... Но это все бред и никак не связано с достижением результата в разрезе — работающего качественного продукта, а связано с методами получения бабла компанией посредником.
1. Нужно как можно меньше общаться друг с другом, не только в рамках компании, но и в команде в целом. Просто берем задачу из списка и делаем ее — без лишних слов. Общение ни к чему доброму не приведет и только увеличит количество проблем и вопросов.
Это хорошее место. Больше митингов хороших и разных! (к) (тм) Всякое общение должно занимать не менее 2 часов. Цели каждого отдельного общения не должны ставиться и доводиться до сведения участников перед его началом тем более задолго до цели должны проясняться в ходе самого общения. Идеально цели не должны проясняться в т.ч. и в ходе самого общения что даёт возможность продолжить общение в другой раз на эту же тему ранее не заявленную и не выясненную в ходе общения текущего. Результатом общения должно быть последующий список вопросов для обсуждения в ходе выполнения перед непосредственно началом выполнения и в случае наступления выполнения в ходе самого выполнения. Результатом выполнения должна быть тема для общения. Всякий результат должен быть представлен в виде отдельной презентации в специально отведённом для представления результатов общении. Последующее общение будет направлено на обсуждение исправлений результата представленного в прошлом общении. Также не следует забывать периодические общения с вертикалью управления начиная от отдела кадров и заканчивая высшим менджментом той вышины что удостоит своих программистов личным общением.

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

ЗЫ: равно как и бросается в глаза резкое различие «общения как карго-культа» против очень конкретного и цинично-бездуховного «общения исключительно в случае необходимости решить конкретные вопросы».

ЗЫ: обобщать конечно неправильно и «оттуда» также есть представители «общения ради общения» но здесь начинается интересный нюанс по которому есть вопрос что первично отечественное «стремление к общению ради общения» притягивает именно такого рода контингент в отличие от чёрствых и бездуховных «других». Кстати два типа довольно качественно выявляются уже на первых контактах.

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

12. За рефакторінг бити руці. Заборонити це слово взагалі. Наляканий цим словом замовник до ваших послуг ніколи не повернеться і краще віддасть проект індусам які цей термін давно прокляли і не гаять час і гроші вельмишановного клієнта

Бывает конечно, лучше говно писать и говорить у нас все по красоте...

Да, и забаньте DOU. Тут одни гадости пишут.

Не увольняйте менеджера, трём оставшимся будет скучно играть в преферанс.

мы же работаем в вакууме и вроде как кони
Якщо не помиляюсь, правильно буде — “лошади”.

P.S.: Стаття цікава.

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

Если же в случае успешного завершения проекта/итерации, будет значительное поощрение (а не тортик) всех участников, то люди сами организуются без этих ваших 500 страничных талмудов кто перед кем первым должен кепку снимать.

Это не совсем сокращение, это обьединение к одной сути и общему направлению. В таком нулевом правиле что-то все же может пойти не так и случится чудо. А 10+ шагов позволят свести вероятность чуда до 0.

Попробую детализировать Oleg Kariakin:
* заинтересуйте команду выполнить проект (деньги, повышения и пр.) и 80% из 10+ пунктов уйдут автоматически — появится саморазвитие, самоорганизация и пр.
* а вам останется менеджить 20% — межличностные отношения и форс-мажоры
...
Описанные пункты — очень характерны для аутсорс\аутстаф моделей, где связи затраты — результат почти нет, вот и вырисовываются подобные «проектные особенности»

заинтересуйте команду выполнить проект (деньги, повышения и пр.)
Кстати не получится сугубо краткосрочный эффект с технической точки зрения.
сугубо краткосрочный эффект
для отдельно взятого сотрудника.
...
Да, синусоиды у всех разные, планы на жизнь тоже, главное чтобы в любой момент времени 80% коллектива была заинтересована в конечном результате.
Описанные пункты — очень характерны для аутсорс\аутстаф моделей, где связи затраты — результат почти нет
Хм. Ну за аутстаф судить не могу, а в аутсорсе — Вы точно уверены в этом тезисе?

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

Скажем так, связь затраты-результат в аутсорсе ниже чем в продуктовой компании.
А точно не наоборот? :)
Аутсорс — выдали рейт, разработали, отдали, ну может следующая версия и\или поддержка.
Это если компания делает на потоке мелкие проекты для кучи сменяющих друг друга клиентов.
А если в работе 3-4 проекта на много десятков человеколет с устоявшимися командами — картина немножко другая.
Соответственно, в контексте статьи, при такой модели у вас нет большого финансового плеча, чтобы мотивировать команду — опционы например.
Всё зависит, и не одними только опционами ограничиваются возможности мотивации.
Ну и строчка в резюме — участвовал в разработке убер-мега продукта (как аутсорсер), тоже слегка блекнет по сравнению с перманентными сотрудниками компании для которой и разрабатывали продукт.
Чепуха.
А точно не наоборот? :)
Не принципиально, здесь связь внунаправленная
Это если компания делает на потоке мелкие проекты для кучи сменяющих друг друга клиентов.
А если в работе 3-4 проекта на много десятков человеколет с устоявшимися командами — картина немножко другая.
1y Materialise/R&D center(~80), 1.5y Epam/Barclays(~500), 3y GL/BMC(~150) — я знаю о чём говорю.
Всё зависит, и не одними только опционами ограничиваются возможности мотивации.
Например? Возможнсти всех других способов сходят на нет, как только человек обзаводится семьёй и детьми.
Чепуха.
Простите, но голословные фразы просто добавляют байтов в DB Доу.
У меня есть знакомый, который уже 4 года работает в фейсбуке,
второй знакомый, работает на долгоиграющих аутсорс-проектах гугла в Украине.
Мое мнение основывается на данных из первоисточников.
здесь связь внунаправленная
А?
Што. ©
1y Materialise/R&D center(~80), 1.5y Epam/Barclays(~500), 3y GL/BMC(~150) — я знаю о чём говорю.
Ну разумеется, а я из пальца на диване высасываю.
Мое мнение основывается на данных из первоисточников.
А мое с потолка.

я знаю минимум одну такую контору :)
хотя может там уже изменилось все

Апплодирую стоя!

7. Не стоит поощрять желание к саморазвитию. Это приведет только к потере времени, денег и нигде больше не пригодиться. Более того, ваша команда получит новые скиллы, попросит повышения оплаты или просто пойдет применять их в другом проекте. Ваше собственное саморазвитие и, тем более, команды — пустая трата ресурсов. Лучше сказать клиенту, что возможна скидка на создание продукта, так как разработчики все еще из прошлого века.
Очень много менеджеров почему-то так и поступают.

Да-да, ужасный подход. Надо всегда всё делать только на самой новейшей и моднейшей технологии, а если вдруг в процессе разработки появилась еще более новейшая и моднейшая — не откладывая начинать переписывать всё на ней. И разработчиков из прошлого века увольнять не раздумывая (лучше всего ввести возрастной ценз, скажем лет 30, а лучше 27 — а то после этого способность обучаться новому резко падает). Набирать людей не по критерию интеллекта и/или опыта, способности работать в команде и т.п., а по критерию жажды изучать и применять всё новое. Задачи между разработчиками распределять исключительно по критерию того, как конкретная задача поможет изучить что-то новое конкретному девелоперу. Ни в коем случае не позволяйте мыслям о продуктивности, сроках, качестве и надежности кода, и эффективности работы, закрадываться и сбивать вас с правильного пути! Тогда и только тогда, ваша компания/команда будет процветающей, разработчики буду мечтать в нее попасть (а те кто есть — дорожить своим местом как ничем в жизни), а на улице всегда будет стоять очередь из жаждущих с вами сотрудничать клиентов!

А как вы убивайте свои проекты? :)
Ломаем полностью!

12. Не пробуйте використовувати GIT/SVN чи щось подібне — це пуста трата часу, просто робіть копії папок з проектами

так так, це 13-й пункт ))

Назвать бы хоть одну которая реализовала все 12 пунктов?

Я подозреваю что в большинстве контор о них даже не подозревают :-(((

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

а еще можно просто вбегать каждые 2 часа и спрашивать «ну как дела»? Этого с головой хватает чтобы прибить менежджера на такой 2-3 инерации

Но вы же, как адекватный сотрудник, понимаете, что некоторые решения диктуются бизнесом и от менеджера не зависят — и поэтому адекватно реагируете на такие ситуации?

Но вы же, как адекватный сотрудник, понимаете, что некоторые решения диктуются бизнесом и от менеджера не зависят

У менеджера есть прекрасный инструмент для таких случаев — установка приоритетов задач в следующем спринте.

Да ну, прод лежит из-за бага — давайте его запланируем на следующий спринт.

Не нужно пытаться рационализировать. Речь шла не о багах, а о новых фичах.

І багато проектів ви «вбили» таким чином?

Ни одного. Занимаюсь управлением риска возникновения таких вот «советов» в своей работе.

Дмитрий, стесняюсь спросить, какие стратегии управления Вы применяете к такого рода рискам?

Вместе с командой перед началом проекта пишем список с набором следующих полей: вероятность; критичность; влияние на проект (время/деньги); маркеры предшествующие возникновению риска; что можно сделать во избежание; что делать в процессе когда риск уже проблема; ответственный. Данный список позволит отслеживать и управлять рисками. Главное не забыть, что у тебя такой список есть, да еще и уведомить дополнительно всех заинтересованных в выполнении проекта.

Главное коммуникаций побольше! Всех со всеми.

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

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

В случае отсутствия репорта хотя бы одного члена команды — объяснительные письма пишут все сотрудники отдела ...

In scrum we trust !

Дмитрий, Ваш ответ из серии: «My name is Boris...»
Я не прошу Вас цитировать ПМБоК, я задаю конкретный вопрос: какая стратегия по управлению любым из упомянутых Вами рисков на Ваш выбор.

Использую несколько:
1. Страхование
2. Избежание
3. Сокращение

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

Вспоминаю свою первую работу и вопль шефа: «Ты должна стать главным бухгалтером за месяц, я сказал!». И кулаком по столу.

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