Как стать автором
Обновить

Комментарии 44

Предположим Вы PM. У вас есть проект который должен быть написан на языке, который вы не знаете. Есть два разработчика. Один предлагает использовать одну библиотеку, второй другую. Аргументы по силе одинаковы. Сами разработчики договориться не смогли. Как развязать конфликт?
Шаг первый: договариваемся с разработчиками о метриках. Тоесть что нам надо от проекта — сделать быстро, сделать расширяемо итд. Разработчикам предлагается реализовать ма-а-а-а-аленький кусочек проекта, буквально на час, с использованием выбранных ими библиотек. А затем написанный код они защищают друг перед другам по метрикам. У кого получается длиннее, того и тапки.
предлагаю тогда еще и отвечать на эти вопросы авторитетным ПМам, будет интересно посмотреть на их опыт :)
я думал над этим, но боюсь, что получится каша. наверное, лучше выбрать вопросы с наибольшим количеством плюсов и создать отдельный топик для ответов на них.
хотя… вы правы, давайте сделаем. обновил топик
1. У вас в подчинении сотрудник, который регулярно затягивает отчеты о выполненных заданиях на срок от получаса и до нескольких часов. Соответственно, на последовательностях задач теряется до 50% времени от того, что приходится самому выяснять закончил человек или нет. Какие есть эффективные способы сделать так, чтобы Вы узнавали о выполнении сотрудником его задач сразу после их выполнения, а не когда подойдете к нему в следующий раз поинтересоваться прогрессом.
как вариант — перед началом выполнения задачи, сотрудник сам называет срок выполнения и время сдачи. я думаю что в таком режиме можно поработать недельку и сопоставить его прогнозы и факты. если причина несовпадения неуважительна — я бы снимал рабочие часы. в денежном эквиваленте.
наказывать рублем не всегда эффективно
тем более как можно оценить уважительность причины?
наказывать менее эффективно чем мотивировать, поощрять
>как можно оценить уважительность причины?
если я сам специалист в области работы сотрудника — без проблем.
>наказывать менее эффективно чем мотивировать, поощрять
я не могу поощрять человека, который несознательно выполняет свою работу.
Я знаю что есть такие которых ничего «не берет», но даже в безнадежных случаях помогает заинтересовывать.
согласен.
в моей практике даже попался такой, которого абсолютно ничем не удалось заинтересовать. премии, бонусы, надбавки, затем штрафы, пригрозили увольнением (дали так сказать новый исп.срок) но как только человек понимал что «жареным уже не пахнет» всё возвращалось на круги своя. на пятый раз таки уволили. нового человека не брали. команда в производительности не потеряла. се ля ви
Как вы предлагаете заинтересовывать безнадёжный случай?
Вроде бы проблема не в том, что он выполняет работу не в срок, а в том, что он не в срок отчитывается о проделанной работе?
учитывая что список задач не маленький — не в срок отчитаться о выполненной задаче = не в срок получить новую. соответственно пока я отчёт не получил — задача не решена. остальное — не моя головная боль.
Значит время отметки о проделанной работе и есть срок выполнения работы. Не отметил до обеда, что сделал задачу, а отметил вечером — получи награду самого медленного работника месяца с вытекающими.
Блин, я почему-то не подумал в таком ключе(

Тогда да, абсолютно согласен.
Нужно сделать так, чтобы человек был мотивирован писать много отчетов о выполненных задачах в некоторый период времени. Как вариант, считайте количество одобренных вами отчетов (а значит выполненных задач) в неделю. Дальше дело техники — поощряйте хороший результат, порицайте плохой и система заработает.
видимо, надо упростить создание отчетов сотрудниками :)
о некоторых задачах извещения могут и вообще автоматически генерироваться. я конечно не совсем ПМ, но использую для создания общей рабочей среды с сотрудниками Дропбокс и о том, что к примеру нарисован баннер могу узнать даже в кафе с телефона. так же можно сделать для более широкого круга задач.
1. Если мне завтра нужны будут C# (PHP/JAVA и т.д.) программисты, сколько у вас есть на примете кандидатов?

2. Сколько книг по управлению прочитали за последние полгода? (банально, но важно)

3. Как вы управляете рисками на проекте?
1. 1000 — у меня учетка в хх.

2. ни одной. и вообще не читал, а вот подишь ты. Ленин, Сталин, Рузвельт, Гейтс есть мнение тоже не читали, а все на практике осваивали. У вас бы они пм не стали.

3. Управление рисками — это анекдот, придуманный теми, кого раз в 4-5 лет трогает за жопу очередной кризис. Реально рисками никто не управляет и управлять не может, это тоже самое, что менеджер — это управляющий клиентами.
по-моему менеджер управляющий клиентами — это очень круто))))
Книги — это знания и опыт, их важность глупо недооценивать.
1. Как завершать проекты в назначенный срок не работая сверхурочно?
2. Должен ли ПМ быть лидером команды?
1. Грамотно эстимейтить. Всем работать не покладая рук.

2. Не обязательно, наставником — да.
1.1. Назначать сроки с запасом.
1.2. Держать руку на пульсе и палить проблемы по мере возникновения, а не когда их уже не смогут больше скрывать. Люди почему-то любят оттягивать конец :)
1.3. Сперва делать прототип и proof of concept, а затем уже кОдить.
1.4. Делить проект на небольшие куски и реализовывать их по очереди, а не «месяц потеряем, потом за секунду телепортируемся».
1.5. Ставить задачи в правильной последовательности. Сначала — нужные и сложные с максимальными рисками, а плюшки и рюшечки в конце.

2. Если он совмещает должности PM и Lead Developer — то да. Если же есть отдельная должность Lead Developer — то задача PM нанять такого, который стал бы в команде лидером. Как показывает практика, команды без разумной доли тоталитаризма летают плохо O_O.
1. Приводящие к качественным результатам и в срок. Самоорганизация и понимание зависимостей в команде.
2. Два условия если, первое: новички — значит рассмотреть задачи как тестовой на основе которой один из двух станет сотрудником другой уходит; втрое, уже сотрудники: они часто перемежаются в итоге каждый из них принимает результат работы другого для завершения общего задания в итоге оценивая сроки на типовые задачи и понимая почему «тогда, а не потом и зачем это нужно сейчас» осознавая потоковость и последовательность процесса разработки; доп. мотивация материальная поэтапная, с градацией по срокам + за качественный результат, все расчеты публичны с исполнителями.
3. Контекст. Без контекста: команда абсолютно бессмысленная тот же ПМ должен быть в роли либо программиста или тестера иначе не рационально, если мы эту команду рассматриваем как лошадь в вакууме.
1) Насколько вы ленивый человек? (Покажет степень объективности по отношению к себе)
2) Найдите 3 применения карандашу, кроме прямого назначения. (креативность, способность найти быстрые решения)
3) Какими PMA Вы пользуетесь как PM? (Опытность в различных проектных примочках)
4) Какими интернет сервисами вы пользуетесь в повседневной жизни и для каких целей? (Кругозор и понимание происходящего интернет сообществе)
5) Неизвестная хворь покосила 2х из 5х ваших девелоперов, проект сдавать на следующей неделе, для заказчика это критичный срок. Ваши действия?
1) достаточно для того что бы скапливать гору грязной посуды но тратить всё нужное(и возможное) время для выполнения задач в срок.
2) 1. заколоть волосы (для девушек), 2. на закреплённый вертикально карандаш можно накалывать бумажки с мелкими заметками, 3. им можно размешать сахар за неимением ложки (желательно конечно карандаш сначала помыть)
3) MSProject, Project expert (если я правильно понял вопрос)
4) googlecode, googledocs, evernote, googlereader, twitter
5) a) самый очведный — оставшихся троих замотивировать примиями поработать сверхурочно. б) если я сам специалист в сфере занятости заболевших — включусь в работу сам. (возможно объединение пунктов «а» и «б». в) неплохо бы иметь на примете пару фрилансеров для вот таких вот ситуаций.
5-в) по Бруксу, введение в проект доп. рабочей силы перед дедлайном только замедлит темпы разработки. Объясняется коммуникациями(новые люди будут отвлекать остальных, задавать вопросы и т.д)
Брукс дэцл не в кассу, потому что Брукс писал о Действительно Больших Софтверных Проектах. а не о говносайтах за 3 копейки.
5) ещё один из вариантов, который для меня самый наиболее предпочтительный — получить список той функциональности, которой ещё нет, понять сколько мы сможем сделать и вместе с заказчиком решить чего делать не будем или чем заменить. Если заменить/упростить ну никак нельзя (хотя тут надо быть «политиком»), то уже тогда искать фрилансеров, овертаймы и прочее.

Это будет менее больно, чем понадеяться на себя/фрилансеров и поставить под угрозу сдачу с самого начала.
Если не секрет, PMA — это Project Management Application? Термин Вы сами придумали, или это из какой-то книги / курса? А то википедия молчит O_O?
Я имею в виду именно акроним PMA :). Словосочетание целых слов, понятное дело, популярное.
Три вопроса, три слова, три буквы. Ага. Наверняка автор этих вопросов еще и курс какой-нибудь продвигает по пм. Угу.

Вообще, желание выявить ПРОФЕССИОНАЛА, задавая ему вопросы, приблизительно тоже самое, что выявить хорошего вояку, задавая ему вопросы, какие методы психологической защиты вы можете привести. Желание решать сложную проблему методичкой сразу выдает студента, мечтающего о карьере преподавателя, но нерешающегося ее начать в виду отсутствия денег.

Я выявляю хороших ПМ очень легко: у меня есть мелкие инет магазины, я даю их в управление и говорю, сможешь увеличить прибыль на х% за месяц, будешь работником, нет — нет. 80% отказываются сразу, 19,5% показывают, что ничего сделать не могут.

Отсюда очень простой вывод: не то пм, что на дать красивые ответы может, а тот, кто решить проблему без бабла способен.
поправьте, если я ошибаюсь, но разве в задачи ПМа входит управление прибылью инет-магазина? о_0
не входит) но интересно мыслить должен, не теряться в любой жизненной ситуации

жизнь полна подарков и сюрпризов)
Сколько вами выявлено ПМов (в чел.) и за какой срок таким образом?
И вопрос повис без ответа(
а цифры вообще релевантны?

скольких через такое сито пропустили?

очень похоже на бла-бла, к сожалению
1. Ведущий программист проекта хочет уволится, проект завершен на 60% ваши действия?
2. Вы не являетесь специалистом но вам нужно оценить актуальность сроков выполнения задачи, Ваши действия.
3. Какие методы мотивации, кроме финансовых, вы знаете и переменяет?
1.1. Попытка избавить ведущего программиста от этого желания — деньги, перспективы, новое кресло наконец.
1.2. Если он жестко решил завязать с программингом и уйти в парикмахеры, то попытка сделать так, чтобы он нашел и обучил себе приемника. «А то, мужик, не по понятиям».
1.3. Если в парикмахеры он хочет уходить через неделю, то попытка убедить его передать дела тому, кого найму на его место.
1.3. Если и это не получилось — найм нового ведущего программиста из пула, натравливание его на текущего чтобы совершил приемо-передаточные работы.

2. Спросить у тех кто является специалистом :). stackoverflow.com, rentacoder.com и прочие волшебные места.

3. Людей нужно время от времени хвалить (с).
1) зависит от того, какова роль ведущего. Бывает, это обычный разработчик, лишь чуть ближе к телу; бывает — функционер, а бывает он тянет 50-70% codebase, несмотря на наличие еще десятка программистов. Т.е. сначала — определяем степень «незаменимости». И далее, в зависимости от — действия могут быть от немедленного увольнения до применения всех средств удержания :) В общем, слишком пространный вопрос, на собеседовании он тянет на отдельную дискуссию, минут на 20-30.

2) задача целостна? — опрос фрилансеров — знакомых или через биржу; иначе — опрос знакомых гуру в этой технологии. А как первичный фильтр использовать здравый смысл + просьба разбить задачу на более мелкие, по возможности не превышающие 4-6 часов.

3) нефинансовые — совместное времяпрепровождение ( отдых и пьянки — как частные случаи ). Ну и идеологическая обработка — сотрудники должны видеть и понимать значимость — свою и результатов своего труда. Если у компании есть возможности — надо пытаться помогать сотрудникам решать нерабочие ( бытовые ) вопросы — аренда, регистрация, мед. помощь ( 50-80% оплата страховки — но не 100% ), частичная оплата спорт. зала, различных занятий.
Ну и комбинации, само собой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории