Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать.
Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений.
Здравствуйте, michael_isu, Вы писали:
EW>>По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать. EW>>Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений.
_>Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
Её нужно либо решить коллективными усилиями, либо обойти. При этом совершенно необходимо избегать личных претензий и намёков на какое-нибудь там "недостаточное качество" специалиста. Перед любым спецом время от времени встают проблемы, которые не удаётся решить с наскока, это: а) нормально, б) не предсказуемо, в) ничего страшного. Не разрешаются только те проблемы, которые никто не разрешает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, michael_isu, Вы писали:
EW>>По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать. EW>>Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений. _>Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
помочь ее решить.
это можно сделать самому, если есть соответствующий опыт.
или при помощи стороннего специалиста (другого сотрудника имеющего опыт или внешнего специалиста).
а это разве не очевидно?
Здравствуйте, michael_isu, Вы писали:
_>Здравствуйте, Ed.ward, Вы писали:
EW>>По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать. EW>>Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений.
_>Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
Помочь её решить. Научить решать подобные задачи самостоятельно.
А главное научить сообщать о затыках в работе самому. Но это зависит от менеджмента. Если за неспособность решить проблему наказывают, разработчик будет скрывать и тянуть сроки.
Гмм. А твоя-то роль в этой петрушке — какая? Если ты такой же рядовой разработчик или вообще сторонний наблюдатель, то — продолжай наблюдать, чем кончится, пусть проблему решают те, кому за это деньги платят. А вот если ты менеджер проекта — ты обязан вмешаться, если есть риск срыва сроков, это твоя служебная обязанность, за это ты деньги получаешь.
1. Откуда вообще взята магическая цифра "160 часов"? Это оптимистиная, пессимистичная или средняя оценка? Как она получена — почему не ровно 100 или 200? Риски при планировании рассматривались? Есть у тебя план управления рисками? Какие действия предусмотрены для риска "Риск срыва сроков"? Как он идентифицируется?
2. Почему "объяснения этого не пустые, но достаточно размытые"? Ты не можешь оценить реальное состояние дел? Привлеки специалиста более высокого уровня (эксперта), чтобы он оценил масштаб катастрофы, предложил способы преодоления проблемы и оценил сроки. Спецификация на модуль есть? Насколько подробная? Описывает ли она (и предусматривает ли вообще) те проблемы, с которыми столкнулся разработчик?
Здравствуйте, Tilir, Вы писали:
T>Здравствуйте, AlexNek, Вы писали:
AN>>И что кто то соглашался? Я бы послал немедленно, ну или по крайней мере попросил бы выбрать или работа или отчеты.
T>Спорный вопрос. Мне вот, например, нравится писать начальству насыщенные подробностями недельные отчёты, систематизируя и приводя таким образом в порядок всё, чем я занят, в первую очередь у себя в голове. При этом читают их или нет, мне пофиг. Это как рассказать всё воображаемому другу. Только лучше. Так что может и действительно сработало. Я вот, если закапываюсь, делаю свои сеансы бесед с воображаемыми коллегами несколько чаще, у меня к счастью есть отдельная доска с маркерами и я на ней рисую, обсуждаю за двух-трёх человек одновременно и многое таким образом решается.
Таких как ты очень мало.
Потом есть разница между добровольным писанием отчетов раз в неделю
и обязаловкой писать отчеты три раза в день.
AN> Если этапы сдаются в срок и не слышно "криков" из команды, то как работает менеджер "внизу" руководству должно быть по барабану.
Это в теории. А на практике, руководству очень часто хочется "чего-нибудь поруководить". Особенно если это какое-нибудь очередное промежуточное руководство, еще одна прослойка ненужных менеджеров. В России обычно и вовсе важно не то, как "этапы сдаются в срок", а то, кто с кем учился, в бане парился и по девкам бегал.
SD>>Видать, у вашего шефа слишком дофига свободного времени. AN>Как раз нпоборот.
Было бы как раз наоборот — шеф бы задавал приоритеты, а не сам лез в технические детали.
AN>Еще полезно просто рассказать о решении коллегам.
А вот с коллегами вы некрасиво поступаете — "рассказываете о решении". Очень некрасиво выглядит, будто вы там с шефом интриги ведете, и вообще "оторвались от коллектива". Понимаю, что, видимо, вы так ведёте свой карьерный рост (традиционно, кстати, для российских "манагеров"), но команде это всегда не нравится. Вы должны с коллегами обсуждать решение, а боссу его "просто рассказывать".
Здравствуйте, AlexNek, Вы писали:
AN>И что кто то соглашался? Я бы послал немедленно, ну или по крайней мере попросил бы выбрать или работа или отчеты.
Спорный вопрос. Мне вот, например, нравится писать начальству насыщенные подробностями недельные отчёты, систематизируя и приводя таким образом в порядок всё, чем я занят, в первую очередь у себя в голове. При этом читают их или нет, мне пофиг. Это как рассказать всё воображаемому другу. Только лучше. Так что может и действительно сработало. Я вот, если закапываюсь, делаю свои сеансы бесед с воображаемыми коллегами несколько чаще, у меня к счастью есть отдельная доска с маркерами и я на ней рисую, обсуждаю за двух-трёх человек одновременно и многое таким образом решается.
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи.
Из этого следует, что причины есть, они действенные, но почему-то не озвучиваются. Исходя из априорной добросовестности получаем, что человек не может чего-то понять — вот он и "тормозит", поскольку размышления требуют времени.
_>Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
Тактично и вежливо вмешаться в процесс решения. Часто бывает так, что специалисту для принятия окончательного решения не хватает какой-то информации, но он сам не может понять, какой именно. Это едва ли не сильнейшая проблема в нашем деле — когда не можешь сообразить, какие именно вопросы нужно задать. Отсюда и пляши.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Vlad_SP, Вы писали:
V_S>1. Откуда вообще взята магическая цифра "160 часов"? Это оптимистиная, пессимистичная или средняя оценка? Как она получена — почему не ровно 100 или 200?
Всякий менеджер знает, что в человеко-неделе 40 часов, поэтому 4 человеко-недели выглядят в проджект-плане красивее, чем 2,5 или 5
Здравствуйте, SkyDance, Вы писали:
AN>>С этим можно скорее согласится, чем возражать. Однако я бы ввел понятия: философия/стиль работы компании и умность менеджера. AN>>С "умным" менеджером почти всегда будет хорошо работаться.
SD>Вне всякого сомнения! Особенно если кавычки от слова "умный" убрать, а то как-то двусмысленно уж очень.
Вообще то я поставил кавычки по другому поводу. Все же понятие умный никак нельзя измерить или коротко описать. SD>Вот только даже самый что ни на есть хороший менеджер из конторы вылетит, если не будет соответствовать принятым (более высокими, но не факт что столь же хорошими) менеджерами правилам.
Ну тут я бы еще поспорил. Если этапы сдаются в срок и не слышно "криков" из команды, то как работает менеджер "внизу" руководству должно быть по барабану.
AN>>А стиль работы компании, практически невозможно изменить парой "умных" менеджеров внизу цепочки.
SD>Я про то и написал. То, что пара человек пишут хорошие и правильные вещи на форуме, никак не говорит о том, что происходит в компании, где они работают.
AN>>Бывало часами спорили, зато потом находилась гораздо лучшая идея.
SD>Видать, у вашего шефа слишком дофига свободного времени.
Как раз нпоборот. Но если прикинуть сколько нужно времени на реализацию неудачной идеи, то пара часов вполне оправданное время. Так как всегда имеется какой либо результат после.
Еще полезно просто рассказать о решении коллегам.
Здравствуйте, michael_isu, Вы писали:
_>Здравствуйте, Vlad_SP, Вы писали:
_>Моя роль — разработчик. И я порой попадаю в описанную ситуацию. Реакция менеджера — никакая, ждать. Периодически спрашивая не готово ли, с каждым разом всё с бОльшим недовольством ("ты же обещал сделать уже!").
Надо не ждать вопросов, а информировать заранее о проблемах. Ну типа если надо сделать "печать" до 30 и проблем вроде не было, но вдруг 5-го обнаруживатеся, что задачу на которую планировался день можно решить только за неделю. Тогда это должен знать немедленно менеджер проекта, а не так что когда он спрашивает тебя 25 — ну будет готово в срок, ты говоришь нет.
_>Берется ТЗ, разбивается логически на некоторые части, каждая из них разбивается на задачи, каждая задача оценивается. Проекты — веб-приложения, порталы. Оценивают обычно 2-3 разработчика, через estimation-покер. Ну т.е. такой-то раздел сайта — столько-то часов, такое-то проектирование — столько-то, такая-то страница столько-то и т.д. В сумме например получается 160, к примеру. Получается примерно средняя оценка. Риски менеджером учитываются, но понятное дело я о них не в курсе.
Планирование конечно хорошо и полезно, но мне еще не попадался план который бы "работал правильно".
_>Опишите целиком как вы решите описанную в первом посте проблему, по шагам, начиная от понимания, что время расходуется сверх запланированного и заканчивая тем, что задача закрывается. К кому обращаетесь, как перераспределяете план работ других людей, которых привлекаете к помощи, как контролируете что процесс сдвинулся, может ещё что-то.
Не знаю как это можно описать в одном абзаце. Да и у каждого будут свои мнения. Ну и от конкретной команды очень много зависит. Нет единного поведения для всех случаев. Всегда нужно ориентироваться по конкретной ситуации. Что хорошо "работает" в одном месте может быть совершенно нерабочим в другом.
Мне кажется, важно иметь долгосрочные и краткосрочные планы. Долгосрочный план включает этапы "сдачи" проекта, он может корректироватья только в особо исключительных случаях. Краткосрочные планы ведут к концу этапа и могут корректироваться довольно оперативно. Я вообще сторонник top-down стратегиии (хотя можно некоторые элементы делать как down-top), поэтому на каждом этапе должна быть рабочая программа которая с каждым разом делает все больше и больше. Как минимум, можно ее регулярно сверять с планом.
_>В будущем мне нужно будет менеджерить проект, хочется знать как общественность поступает в таких ситуациях.
Не думаю, что изучив десяток рецептов можно стать менеджером. Да и это может быть "опасно". Вот реальная ситуация, свидетелем которой я был.
Был один неплохой программист, сделавщий один несколько хороших проектов и пришла ему в голову идея другого проекта, но это проект ему было одному не потянуть и решило руководство сделать его ПМ-ом и дать ему команду. При этом теоретические знания о руководстве проектом у него имелись в достатке. Поначалу шло вроде неплохо, отчеты об этапах были радужные, планы — Наполеоновские, но потом всем потихоньку стало понятно, что проект "буксует", уже было хотели его даже уволить, но потом приняли более компромиссное решение. Нашли "старого" ПМ-а имеющего большой опыт в других (не программных) проектах, а этого просто "перевели" в члены команды. В итоге проект "ожил" и видимо будет успешно "сдан".
_>Берется ТЗ, разбивается логически на некоторые части, каждая из них разбивается на задачи, каждая задача оценивается. Проекты — веб-приложения, порталы. Оценивают обычно 2-3 разработчика, через estimation-покер. Ну т.е. такой-то раздел сайта — столько-то часов, такое-то проектирование — столько-то, такая-то страница столько-то и т.д. В сумме например получается 160, к примеру.
Напомню, что в результате такого мероприятия у вас получаются не часы, а "идеальные часы". Их ни в коем разе нельзя путать с реальными часами — теми, которых 40 в неделе. Скорость (burndown) нельзя авторитарно установить в "1:1" — но на основе сколь-нибудь длительных наблюдений можно посчитать (и после чего уже автоматом корректировать сроки). Напомню про "треугольник" (или "пирамиду" — кому как привычнее): если у вас фиксированы ресурсы (разработчики) и скоуп (фичи), нельзя зафиксировать время (и/или качество — если брать "пирамиду").
Короче говоря, на этапе оценки вы не можете получить настоящие "часы". А если у вас кроме этого проекта еще есть другие (например, багфиксы старых или консультирование коллег) — тем более.
_>Например, при пополнении баланса пользователя на сайте он должен получать акты, в .doc и .xls-формате, либо в подобных, с которыми умеет работать MS Office. Нужно это реализовать, офиса на сервере нет и не будет. Задача для меня например в некоторой степени исследовательская.
Ух, ну а тут вы вообще не можете давать оценки! Даже в идеальных часах! Один из хороших рецептов, практикующихся в Agile — выделить time box для создания прототипа (то самое "исследование"). Целью (target) этого исследования должна стать как раз ОЦЕНКА того, сколько делать настоящее (production grade) решение.
_>Ситуация такая, что тим-лида нет. Есть просто 5 разработчиков, что-то чуть послабее, кто-то чуть посильнее. И если создавать буфер, то возникают вопросы.
Так это же ваш ШАНС! Берите на себя ответственность. И имейте мужество, обсудив с коллегами, выкатить нормальную оценку, в которую вы уложитесьт — а затем в эту оценку уложиться. Покажите начальству, что с вами можно иметь дело, как со взрослыми людьми. Короче говоря, станьте лидом. Это если вам интересна такая работа (меньше программирования, больше психологии). На самом деле, большинству людей это не особо интересно.
_> Например сейчас я делаю проект один и вопросы типа — вот такой же примерно раздел в другом проекте делался 2 дня, почему здесь 3 дня?
Хм, а правда, почему? Найдите объяснение. Например, посмотрите, а БЫЛ ли сделан тот раздел в соседнем проекте за 2 дня? Или, как обычно, 2 дня делали, 3 переписывали, 5 дней интегрировали и еще 2 недели баги фиксили? До работы через TDD и итерационной разработки я обычно видел 2й вариант. Когда вроде бы всё сделано, но ничего не работает.
_>Хотя в том вот проекте (или нескольких) это все делалось со спринтерской скоростью, там на поддержке черт ногу сломит.
Вот и объясните это. Полностью невменяемое начальство — это редкий случай. Возможно, у него есть больше сведений — например, для бизнеса важно выпустить глюкалище, но завтра, чем супер-стабильный продукт, но послезавтра. Может, у него контракты на поставку горят.
Но вообще, раз у вас есть спецификации, да еще и подробные — да вы вообще в идеальных условиях. Просто давайте разумные оценки, и при попытке наехать "а почему так долго" — нужно очень аккуратно и доходчиво объяснять, что авторитарное занижение сроков не приведет к тому, что продукт выпустится раньше — но нервы будут у всех измотаны.
Вообще, один очень сильный консультант по SCRUM, немец, когда работал с одной (крупной) российской компанией — очень уж он удивлялся этому чисто российскому стилю менеджмента. Он называл его "Please lie to me!" Почему? Он это так объяснял: идет разработка. Приходит новая фича. Начальник (простите, но менеджером назвать его не могу) требовал дать оценки. Команда собиралась, репу чесала, прикидывала, как с наименьшими затратами сделать — и называла, допустим, 2 недели. На это начальник всегда говорил "здорово, а как можно сократить этот срок?" Если разработчики объясняли, что, в общем-то, никак — он задавал этот вопрос в стиле "давайте попробуем уменьшить трудозатраты вот тут-то". Ему объясняли, что не получится — нет необходимой поддержки со стороны другой команды. Он расцветал и обещал полную поддержку другой команды (забегу в будущее — разумеется, оной поддержки не будет). Вот из-за такого давления (и, признаюсь, малодушия членов команды, меня в том числе) назывались заниженные сроки. Их всегда срывали. Всегда. Почему? Потому что начальник требовал не сроки, а "lie to me", т.е. "ну соврите мне, скажите, что это возможно к следующей пятнице".
Почему начальнику это сходило с рук? Так ведь он со всех сторон прикрыт: гадкие разработчики ему наврали со сроками, соседняя команда не оказала посильной помощи (у нее свой начальник, однако), он сделал всё, что мог.
Вылечить ситуацию можно двумя путями. Первый — сомнительный — сменить начальника. Сомнительный — потому что непонятно, на кого, и не факт, что новый окажется менеджером, а не ровно таким же скользким типом (КМК, в 99% окажется). В конце концов, на него тоже будут "давить" сверху, и он ровно так же займется прикрытием пятой точки.
Второй путь — вводить объективные способы оценки, т.е. разделить "оценочные" идеальные часы и те часы, которых 40 в рабочей пятидневной неделе. И вводить поправочный коэффициент (в SCRUM зовут его — velocity), который будет определять отношение между "идеальными" и "реальными" часами.
Ах да, самое главное забыл. Надо наладить систему приоритезации фич, а также процесс выбрасывания фич из очередного релиза. Тогда все будет много проще — если надо "к следующей пятнице", тупо выбрасывается всё, что явно не успевается.
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
Сделай "дизайн ревью".
Пусть разработчик опишет у маркерной доски планируемые изменения с точностью до класса (модуля, что там в вашем языке есть). Пусть его слушают как минимум двое опытных коллег.
И пусть они объяснят ему, в чем проблема в его подходе. Или, если человек не может сам придумать решение, подумают все вместе.
А у него затруднения с подходом к решению есть. Просто он не знает, как об этом сказать.
Это может повторяться несколько раз, пока у проверяющих не останется замечаний. После этого, исполнителю будет довольно сложно объяснить затягивание, и даже если он раздолб — ему ничего не останется, кроме как либо сделать свою работу, либо себе харакири.
_>А как быть тогда разработчикам? Если спускается сверху спецификация (состоящая из одних экранных форм), нужно оценить каждую форму в часах, и если сроки не выдерживаются (именно вот эти идеальные сроки) — прессуют по самое немогу.
Если вот прямо так авторитарно, и чтоб разработчиков вообще ни о чем не спрашивали — создавайте буфера (buffers). Какого размера — вообще говоря, в традиционном менеджменте ("спустили задание") это должен знать Team Lead. Минимальный размер буфера, который вообще можно представить — 20% (но это экстрим, и только для очень опытных разработчиков, которые уже ТОЧНО знают, сколько им делать — вот они ошибаются как раз на эти проценты). Другой экстрим — это правило "умножения на Пи", когда все оценки разработчиков умножают на 3,14(15926).
Но это все равно контрпродуктивно. Разработчики все-таки люди ценные и их всегда не хватает (еще ни разу не встречал конторы, которой хватало бы разработчиков, и которая могла бы легко этими сотрудниками расшвыриваться — в отличие от разных управленцев, аналитиков, и даже QA).
Продуктивнее — идти итеративным подходом и пересматривать оценки, например, раз в неделю (или две, или три, но не реже). Чем дольше вы работаете с системой, тем больше накапливается знания и понимания того, какими должны были быть оценки. Так, например, изначальные оценки были "3 дня на фичу А, 5 на фичу Б, 10 на В, 4 на Г". Через неделю выяснилось, что сделали только "А", ошиблись в оценках в 1.7 раза (неделя = 5 дней = 3 * 1.7). Остальные оценки можно либо механически умножить на 1.7, либо творчески сесть и поставить новые оценки — с учётом новых знаний про систему (например, может статься, что во время реализации А много времени ушло на создание нужных хелпер-классов, и фичи Б, В и Г будет сделать проще, чем думалось изначально).
Выше это были объяснения на пальцах. Если почитать классиков всякого Agile'а, можно почерпнуть много больше и в куда более академическом изложении. Главное — не воскликнуть "Эврика!" и не начать нести agile в массы — вас все равно не поймут, слишком большая инертная масса...
Здравствуйте, michael_isu, Вы писали:
m> Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
Что важнее проблема или проект? Обычно этап проекта важнее. Нужно просто реализовать максимально простое решение проблемы с какими то ограничениями (ну типа, можно открыть только одно окно). Одновременно разработчику рассказать самому непонятливому о проблеме, чтобы он ее понял, затем описать проблему, пути решения, ограничения и пр. После обсудить все командой, наметить пути решения, возможно разбить на подзадачи и раздать их еще кому-то. Разработчику занятся другой задачей не забывая об этой. Обычно через какое-то время решение находится.
Из 5-и человек (вроде столько было упомянуто) хоть один да хочет. Вот и давайте ему поддержку — будет настоящий лидер, не назначенный, а тот, кто сам хотел, и кого поддержали.
>> Почему начальнику это сходило с рук? Так ведь он со всех сторон прикрыт: >> гадкие разработчики ему наврали со сроками, соседняя команда не оказала >> посильной помощи (у нее свой начальник, однако), он сделал всё, что мог. V>Как знакомо.
Начальники на пост-советском пространстве в значительной части одинаковы. Увы.
>> Вылечить ситуацию можно двумя путями. V>Посмотрел бы я на твои действии при противодействии такого начальника V>этим путям.
Пообщаться (с аргументами, а не пустыми обвинениями) с начальством повыше. Вообще, в любой иерархии, если вдруг происходит "перескок ступени" (как там пишут, "через голову начальника"), это сразу вызывает подозрение и более пристальное внимание к тому "начальнику", через голову которого происходит "перепрыг". Потому что, как говорил Винни-Пух, "это ж-ж-ж неспроста, само же дерево жужжать не может". Вон, соседняя ветка это здорово подтверждает.
Тут основной вопрос — готов ли автор к бочкам г---а, в которые придется многократно заныривать, если действительно что-то хочется изменить к лучшему. В моей практике подобное случалось не единожды. И размеры бочки (а также консистенция субстанции) каждый раз становились всё больше. Сначала это была борьба с технической неграмотностью "начальника" (которая чуть не разрушила проект). Для проекта это было хорошо — начальника того вы итоге "сослали" (есть такой способ без выливания тонн дерьма убрать плохого руководителя — передвинуть его на "новый проект", в котором людей еще нет — и, хаха, в будущем тоже на самом деле не будет), проект начал оживать. Но когда на проект пришли ресурсы, туда же пришли и корпоративные паразиты, а к этому никто не был готов. И после полутора лет передышки в проекте опять началась ж..а. "И вновь продолжается бой". В какой-то момент наступает психологическая готовность в любой момент бросить к чертям контору, где работаешь (даже если прикипел к ней, и к коллегам). И это будет самым продуктивным периодом в борьбе — когда терять нечего, когда плевать на угрозы начальства (а что оно может сделать? уволить? а пофигу, пущай увольняет).
Единственное, о чем хочется предупредить автора — ратуя за проект и комфортную (продуктивную) работу разработчиков, лично для себя никакой выгоды получить не удастся. Зарплата не вырастет, уважения не добавится. Максимум, что может быть — дадут грамоту "Молодец, много старался". А так, даже коллеги вряд ли оценят — с их позиций может показаться, будто все битвы против неграмотного начальства целью своей являли лишь "смену власти".
В общем, у меня опыт участия в проектах с отвратительно подобраной "обвязкой" команды (т.е. разработчики — ну просто суперские, но менеджмент — просто караул) существенный. Жаль, что он в значительной части так и остался антипаттерном I told you so. Т.е. я предупреждал — говорил, что надо делать вот так, иначе будут вот такие и такие негативные эффекты для проекта/проектов (например, я говорил, что нельзя занижать сроки путём давления на разработчиков — нельзя делать pleas lie to me). На меня либо ругались, либо говорили, что я ничего не понимаю. По прошествии определенного времени (обычно достаточно большого) — все происходило ровно так, как я и предсказывал. Да, я предупреждал. Меня не слушали. Получали то, о чем я предупреждал. Но вместо того, чтобы начинать слушать — наоборот, начинали страшно злиться и еще больше ругаться.
Справедливости ради, это было лишь в одной конторе, и, более того, лишь в одном конкретном направлении (департаменте, если угодно). Некие намёки на то были и в другой московской конторе, но там я изначально пришел с настроением "я не боюсь угроз увольнения" — и принес много ценных идей и знаний. Которые, жаль, слегка опередили время и уровень развития той компании. Сейчас уже около года я там не работаю, и вот они как раз дозревают до понимания. Искренне желаю им удачи — и думаю, у них получится, там менеджмент куда более вменяемый. Имена контор раскрывать не буду, но скажу — это, по российским меркам, практически гиганты
Сейчас я не работаю в России. Здесь ситуация противоположная: меня слушают и делают так, как надо, и как я говорю. Проект прёт как на дрожжах — он _уже_ окупился, менее чем за год, и, надеюсь, скоро будет на нем заработан первый миллион. А сейчас набираем еще людей и идем распространяться в другие страны. Маленький такой стартап
VD>Я не говорю, что компания окажется обязательно хорошей. Но есть вероятность (скорее мат. ожидание) что в этом случае твоим руководителем не будет человек, случайно попавший на эту должность, или считающий что работа начальника это когда платят больше, а делать нужно меньше.
Чего ж вторую-то часть (в которой суть сосредоточена) цитировать не стали? Мне еще раз ее привести? Так без проблем. Повторяю: даже если менеджер понимает и знает, как _должно быть_, или как _ему_бы_хотелось_ — это не значит, что именно так оно и будет в конторе.
Один, два, даже пять грамотных товарищей влёгкую потонут в сотне "обычных". И никто этих грамотных товарищей слушать не станет (традиционная беда России, кстати, — каждый начальник всегда считает себя умнее всех остальных, и не слушает тех, кто под ним, потому что они by default его глупее).
Тебе уже дали в ветке целую кучу полезных советов коллеги Геннадий Васильев, AlexNek, Gaperton...
Отмечу еще одну проблему, на которую тебе следует обратить внимание: _>Задача для меня например в некоторой степени исследовательская. Ну или например нужно реализовать какую-нибудь простую онлайн-игру, типа морской бой, где нужны вобщем-то навыки ОО-дизайна, а придумать адекватную модель у человека не получается сходу.
Отквоченное свидетельствует о смешении в одну работу задач исследовательских (ну или проектных), которые должны ответить на вопрос "как делать?", и задач чисто технических — когда уже точно известно, "как", и нужно только тупо педалить код. В этом, как мне представляется, и есть причина затягивания сроков — когда разработчику неясно, "как?".
Эти два типа задач абсолютно точно нужно разделить на отдельные работы (не смешиваем мух с котлетами!), причем, по результатам исследовательских или проектных работ должен появиться некий артефакт проекта — возможно, короткая пояснительная записка на 1-2 странички, отвечающая на вопрос "как?". И этот артефакт следует обсудить с коллегами — выполнить дизайн-ревью. По результатам — может быть несколько последовательных итераций дизайна. Ну, а далее — остается только реализовывать.... и тут "объяснения этого не пустые, но достаточно размытые" уже не прокатят.
Здравствуйте, JazzzMaster, Вы писали:
JM>3 раза в день разработчик пишет детальный отчет — что сделано/не сделано, чем занят в данный момент, что планирует с
Нафига ? Проще с ним поговорить.
Ты бы согласился писать три раза в день детальный отчет?
Понятно. То, что вы делаете, называется "юлить". Вот вы сейчас юлите. Во всем вашем посте.
Из-за чего, например, у меня создается впечатление, будто вы старались "подмазаться" к упомянутому персонажу, когда он был каким-то начальником.
И, похоже, вы так же ведете себя в жизни. Потому что:
AN>А то вот сегодня дернул меня черт произнести "умную фразу" — "асинхронный старт второго треда" и погряз на пару часов доказательств о "нафига оно надо", зачем усложнять и т.п.
Вместо того, чтобы просто сказать "а, не надо тут ничего сложного" и потратить 2 часа на полезное дело, вы полезли в бутылку, потратив кучу времени (своего и команды) с неизвестной отдачей. Даже если вы кого-то уговорили и доказали — это может значить лишь то, что они устали с вами спорить и решили плюнуть — делайте как можете, всё равно потом переделывать.
Собственно, на этом и я с вами дискуссию завершаю, т.к. в ее продолжении смысла не вижу. Будьте честнее с вашими коллегами, с шефом, и, главное, с самим собой.
Здравствуйте, SkyDance, Вы писали:
AN>>Там шла речь именно о "периоде шефа".
SD>Понятно. То, что вы делаете, называется "юлить".
А то что Вы делаете называется фантазией на пустом месте (это если не пытаться использовать медицинские термины )
Я просто попробовал дать больше информации, но это вам совсем не требуется, диагноз то уже поставлен SD> Вот вы сейчас юлите. Во всем вашем посте. SD>Из-за чего, например, у меня создается впечатление, будто вы старались "подмазаться" к упомянутому персонажу, когда он был каким-то начальником.
Как говорится, без комментариев.
SD>И, похоже, вы так же ведете себя в жизни. Потому что:
AN>>А то вот сегодня дернул меня черт произнести "умную фразу" — "асинхронный старт второго треда" и погряз на пару часов доказательств о "нафига оно надо", зачем усложнять и т.п.
SD>Вместо того, чтобы просто сказать "а, не надо тут ничего сложного" и потратить 2 часа на полезное дело, вы полезли в бутылку,
А где было описано именно такое развитие событый? SD>потратив кучу времени (своего и команды) с неизвестной отдачей. Даже если вы кого-то уговорили и доказали — это может значить лишь то, что они устали с вами спорить и решили плюнуть — делайте как можете, всё равно потом переделывать.
Не имею никакого желания доказывать обратное. И где, кстати речь шла о споре? SD>Собственно, на этом и я с вами дискуссию завершаю, т.к. в ее продолжении смысла не вижу. Будьте честнее с вашими коллегами, с шефом, и, главное, с самим собой.
Я бы вам порекомендовал меньше фантазировать и не играть в психоаналитика.
Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
Здравствуйте, Ed.ward, Вы писали:
EW>По моему опыту, одним из самых сильных демотиваторов является непонимание, что делать. EW>Я бы в первую очередь поинтересовался, не наткнулся ли человек на проблему, которую он не знает как решить, или не может выбрать из нескольких решений.
Ок, человек столкнулся с проблемой, которую не удается решить. Что делать дальше?
01.04.2011 14:38, michael_isu пишет:
> > Ок, человек столкнулся с проблемой, которую не удается решить. Что > делать дальше?
Ваши действия дальнейшие зависят от того, что вам надо.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, michael_isu,
V_S>Гмм. А твоя-то роль в этой петрушке — какая? Если ты такой же рядовой разработчик или вообще сторонний наблюдатель, то — продолжай наблюдать, чем кончится, пусть проблему решают те, кому за это деньги платят. А вот если ты менеджер проекта — ты обязан вмешаться, если есть риск срыва сроков, это твоя служебная обязанность, за это ты деньги получаешь.
Моя роль — разработчик. И я порой попадаю в описанную ситуацию. Реакция менеджера — никакая, ждать. Периодически спрашивая не готово ли, с каждым разом всё с бОльшим недовольством ("ты же обещал сделать уже!"). Менеджер не в теме программирования, его роль — общение с заказчиком, разбиение ТЗ очередного проекта на итерации, декомпозиция задач, планирование итераций и т.д. (оценкой занимаются разработчики).
V_S>1. Откуда вообще взята магическая цифра "160 часов"? Это оптимистиная, пессимистичная или средняя оценка? Как она получена — почему не ровно 100 или 200? Риски при планировании рассматривались? Есть у тебя план управления рисками? Какие действия предусмотрены для риска "Риск срыва сроков"? Как он идентифицируется?
Берется ТЗ, разбивается логически на некоторые части, каждая из них разбивается на задачи, каждая задача оценивается. Проекты — веб-приложения, порталы. Оценивают обычно 2-3 разработчика, через estimation-покер. Ну т.е. такой-то раздел сайта — столько-то часов, такое-то проектирование — столько-то, такая-то страница столько-то и т.д. В сумме например получается 160, к примеру. Получается примерно средняя оценка. Риски менеджером учитываются, но понятное дело я о них не в курсе.
V_S>2. Почему "объяснения этого не пустые, но достаточно размытые"? Ты не можешь оценить реальное состояние дел? Привлеки специалиста более высокого уровня (эксперта), чтобы он оценил масштаб катастрофы, предложил способы преодоления проблемы и оценил сроки. Спецификация на модуль есть? Насколько подробная? Описывает ли она (и предусматривает ли вообще) те проблемы, с которыми столкнулся разработчик?
Например, при пополнении баланса пользователя на сайте он должен получать акты, в .doc и .xls-формате, либо в подобных, с которыми умеет работать MS Office. Нужно это реализовать, офиса на сервере нет и не будет. Задача для меня например в некоторой степени исследовательская. Ну или например нужно реализовать какую-нибудь простую онлайн-игру, типа морской бой, где нужны вобщем-то навыки ОО-дизайна, а придумать адекватную модель у человека не получается сходу.
Опишите целиком как вы решите описанную в первом посте проблему, по шагам, начиная от понимания, что время расходуется сверх запланированного и заканчивая тем, что задача закрывается. К кому обращаетесь, как перераспределяете план работ других людей, которых привлекаете к помощи, как контролируете что процесс сдвинулся, может ещё что-то.
В будущем мне нужно будет менеджерить проект, хочется знать как общественность поступает в таких ситуациях.
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
У меня есть похожая ситуация. Я тоже разработчик, тоже не могу сделать продукт, затягиваю. Менеджер походит, пытается помочь, спрашивает когда. От слова когда я уже вздрагиваю. В конце концов он меня сдал — на совещании у руководства сказал что у меня недостаточная квалификация. Пришлось согласиться, потому что не нашел других оснований. Наняли другого человека, специалиста в данной области. Пошло немного быстрее.
Здравствуйте, net31, Вы писали:
N>Здравствуйте, michael_isu, Вы писали:
_>>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
N>У меня есть похожая ситуация. Я тоже разработчик, тоже не могу сделать продукт, затягиваю. Менеджер походит, пытается помочь, спрашивает когда. От слова когда я уже вздрагиваю. В конце концов он меня сдал — на совещании у руководства сказал что у меня недостаточная квалификация. Пришлось согласиться, потому что не нашел других оснований. Наняли другого человека, специалиста в данной области. Пошло немного быстрее.
Нормальный менеджер спрашивает, что нужно что бы закончить вовремя.
И на подобные вопросы не отвечают — не знаю. Надо объяснить проблему, чем сложнее объяснение, тем лучше
Здравствуйте, Vlad_SP, Вы писали:
V_S>Эти два типа задач абсолютно точно нужно разделить на отдельные работы (не смешиваем мух с котлетами!), причем, по результатам исследовательских или проектных работ должен появиться некий артефакт проекта — возможно, короткая пояснительная записка на 1-2 странички, отвечающая на вопрос "как?". И этот артефакт следует обсудить с коллегами — выполнить дизайн-ревью. По результатам — может быть несколько последовательных итераций дизайна. Ну, а далее — остается только реализовывать.... и тут "объяснения этого не пустые, но достаточно размытые" уже не прокатят.
Артефакт необходим, если по этому "дизайну" ("эскизному проекту") будет работать кто-то кроме исполнителя.
Или (вторая ситуация), когда проверяющие проверяют удаленно.
Если же "дизайн" делается для себя, и проверяющие физически рядом — доклада у маркерной доски не просто достаточно — а так лучше будет.
Здравствуйте, SkyDance, Вы писали:
SD>Напомню, что в результате такого мероприятия у вас получаются не часы, а "идеальные часы". Их ни в коем разе нельзя путать с реальными часами — теми, которых 40 в неделе. Скорость (burndown) нельзя авторитарно установить в "1:1" — но на основе сколь-нибудь длительных наблюдений можно посчитать (и после чего уже автоматом корректировать сроки). Напомню про "треугольник" (или "пирамиду" — кому как привычнее): если у вас фиксированы ресурсы (разработчики) и скоуп (фичи), нельзя зафиксировать время (и/или качество — если брать "пирамиду").
SD>Короче говоря, на этапе оценки вы не можете получить настоящие "часы". А если у вас кроме этого проекта еще есть другие (например, багфиксы старых или консультирование коллег) — тем более.
А как быть тогда разработчикам? Если спускается сверху спецификация (состоящая из одних экранных форм), нужно оценить каждую форму в часах, и если сроки не выдерживаются (именно вот эти идеальные сроки) — прессуют по самое немогу.
SD>Минимальный размер буфера, который вообще можно представить — 20% (но это экстрим, и только для очень опытных разработчиков, которые уже ТОЧНО знают, сколько им делать — вот они ошибаются как раз на эти проценты). Другой экстрим — это правило "умножения на Пи", когда все оценки разработчиков умножают на 3,14(15926).
Для придирастов, на всякий случай скажу — да, я помню про cone of uncertainty, который предполагает +-80% (т.е. оценки могут варьироваться как в +80%, так и в -80%). Но, во-первых, это уже более продвинутое дао, чем просто "буфер", и к нему нужно еще придти. Во-вторых, я за более чем 10 лет так ни разу и не видел, чтобы программисты успели не то что на 80% быстрее запланированного, а даже на 30% (на 20% видел).
Здравствуйте, SkyDance, Вы писали:
SD>Если вот прямо так авторитарно, и чтоб разработчиков вообще ни о чем не спрашивали — создавайте буфера (buffers). Какого размера — вообще говоря, в традиционном менеджменте ("спустили задание") это должен знать Team Lead. Минимальный размер буфера, который вообще можно представить — 20% (но это экстрим, и только для очень опытных разработчиков, которые уже ТОЧНО знают, сколько им делать — вот они ошибаются как раз на эти проценты). Другой экстрим — это правило "умножения на Пи", когда все оценки разработчиков умножают на 3,14(15926).
Ситуация такая, что тим-лида нет. Есть просто 5 разработчиков, что-то чуть послабее, кто-то чуть посильнее. И если создавать буфер, то возникают вопросы. Например сейчас я делаю проект один и вопросы типа — вот такой же примерно раздел в другом проекте делался 2 дня, почему здесь 3 дня?
Хотя в том вот проекте (или нескольких) это все делалось со спринтерской скоростью, там на поддержке черт ногу сломит. У меня реальные сроки получаются как раз в 1.5-2 раза больше того, что было оценено. Притом, что каждый день возникают десятки вопросов по недоработкам спецификации, на каждый из которых уходит время. А менеджер свирепствует, т.к. есть очень жесткие сроки, которые примерно соответствуют идеальным оценкам.
11.04.2011 10:39, michael_isu пишет:
> > Ситуация такая, что тим-лида нет. Есть просто 5 разработчиков, что-то > чуть послабее, кто-то чуть посильнее. И если создавать буфер, то > возникают вопросы. Например сейчас я делаю проект один и вопросы типа — > вот такой же примерно раздел в другом проекте делался 2 дня, почему > здесь 3 дня? > Хотя в том вот проекте (или нескольких) это все делалось со спринтерской > скоростью, там на поддержке черт ногу сломит. У меня реальные сроки > получаются как раз в 1.5-2 раза больше того, что было оценено. Притом, > что каждый день возникают десятки вопросов по недоработкам спецификации, > на каждый из которых уходит время. А менеджер свирепствует, т.к. есть > очень жесткие сроки, которые примерно соответствуют идеальным оценкам.
Выхода два:
1. Журавль в небе: Разработчики самоорганизуются и начинают плавно
затягивать сроки (и оценки тоже), потиху выводя их на 1.5-2 раза
медленнее реально затраченного времени. После оного манагера возможно
уволят. А кого-то из вас назначают манагером.
2. Синица в руках: Сменить контору.
V>1. Журавль в небе: Разработчики самоорганизуются и начинают плавно V>затягивать сроки (и оценки тоже), потиху выводя их на 1.5-2 раза V>медленнее реально затраченного времени. После оного манагера возможно V>уволят. А кого-то из вас назначают манагером.
Так ведь он же написал — манагеров нет. Значит, как раз там синица и закопана: надо становиться лидом. Отличный шанс. Кстати, не факт, что тот, кого "назначат" манагером, будет лучше — на него так же будет давить начальство. А раз он и раньше не держал давление (соглашался на заниженные сроки), то и потом не будет.
V>2. Синица в руках: Сменить контору.
Это очень спорный вопрос. Упускать шанс на лидерство — неправильно. Сменить контору? На что? А будет ли польза?
12.04.2011 2:02, SkyDance пишет:
> > Это очень спорный вопрос. Упускать шанс на лидерство — неправильно.
Не все хотят и могут быть лидерами.
> Сменить контору? На что? А будет ли польза?
Это уже пусть ТС сам разбирается. Что там за конторы в округе есть?
12.04.2011 1:58, SkyDance пишет:
> > Вот и объясните это. Полностью невменяемое начальство — это редкий > случай.
Не такой уж и редкий.
> Потому что начальник требовал не сроки, а "lie to me", т.е. "ну соврите > мне, скажите, что это возможно к следующей пятнице". > > Почему начальнику это сходило с рук? Так ведь он со всех сторон прикрыт: > гадкие разработчики ему наврали со сроками, соседняя команда не оказала > посильной помощи (у нее свой начальник, однако), он сделал всё, что мог.
Как знакомо.
> > Вылечить ситуацию можно двумя путями.
Посмотрел бы я на твои действии при противодействии такого начальника
этим путям.
Тоже иду по этому пути — ещё в январе по другому проекту предсказывал надвигающиеся проблемы — как раз оценили все очень оптимистично, очень оперативно начали реализовывать модули, спустя 6 месяцев треть времени уходит на фиксинг багов, в один из дней недавно менеджер даже сказал в сердцах разработчикам проекта — "осталось вот этому отвалиться и вообще ничего работать не будет". Спросил так ехидно у него — "ну что, апокалипсис наступает? ". Ответить было нечего.
_>Тоже иду по этому пути — ещё в январе по другому проекту предсказывал надвигающиеся проблемы — как раз оценили все очень оптимистично, очень оперативно начали реализовывать модули, спустя 6 месяцев треть времени уходит на фиксинг багов, в один из дней недавно менеджер даже сказал в сердцах разработчикам проекта — "осталось вот этому отвалиться и вообще ничего работать не будет". Спросил так ехидно у него — "ну что, апокалипсис наступает? ". Ответить было нечего.
Вот, как ни странно, я с высоты нынешнего опыта, наверное, посоветовал бы не повторять мой путь. Ну да, я неслабо так почесал своё эго в итоге. Прокачал скиллы на предмет составления всяких бумаг, планов, прогнозов, учётов и т.п. Но кроме морального злорадства ничего не получил. А вот нервов потерял предостаточно — и овертаймов отсидел выше крыши. Если у вас действительно предапокалиптическая ситуация, то я присоединюсь к рекомендацияю Vzhik оглянуться по сторонам на предмет других контор поблизости. Даже если вы и не захотите никуда переходить, у вас хотя бы появится здоровый пофигизм на тему увольнения — это и нервы помогает сберечь, и уверенности придает (а уверенность — очень важный фактор при разговоре с любым начальством).
Но ситуация у вас прямо классическая для российской разработки
14.04.2011 2:40, SkyDance пишет:
> > Из 5-и человек (вроде столько было упомянуто) хоть один да хочет. Вот и > давайте ему поддержку — будет настоящий лидер, не назначенный, а тот, > кто сам хотел, и кого поддержали.
Если у этого лидера есть голова, то он прежде подумает, чем брать на
себе не понять что.
> > Начальники на пост-советском пространстве в значительной части > одинаковы. Увы.
Такова здесь жизнь.
> >> > Вылечить ситуацию можно двумя путями. > V>Посмотрел бы я на твои действии при противодействии такого начальника > V>этим путям. > > Пообщаться (с аргументами, а не пустыми обвинениями) с начальством
Опущу, все что ты написал. По сути вопрос: Добился ты того, чего хотел в
результате этих разборок?
Я предполагаю, что понырять в бочки с Г. не было твоей целью.
> > Сейчас я не работаю в России. Здесь ситуация противоположная: меня > слушают и делают так, как надо, и как я говорю. Проект прёт как на > дрожжах — он _уже_ окупился, менее чем за год, и, надеюсь, скоро будет > на нем заработан первый миллион. А сейчас набираем еще людей и идем > распространяться в другие страны. Маленький такой стартап
А где объявы? Планируете ли в Беларуси? Где планируете людей набирать?
Тут сейчас сильно зарплаты програмерские просели.
14.04.2011 3:15, michael_isu пишет:
> > Тоже иду по этому пути — ещё в январе по другому проекту предсказывал > надвигающиеся проблемы — как раз оценили все очень оптимистично, очень > оперативно начали реализовывать модули, спустя 6 месяцев треть времени > уходит на фиксинг багов, в один из дней недавно менеджер даже сказал в > сердцах разработчикам проекта — "осталось вот этому отвалиться и вообще > ничего работать не будет". Спросил так ехидно у него — "ну что, > апокалипсис наступает? ". Ответить было нечего.
Ну если ты все нюансы не учел скоро уволишься.
Здравствуйте, SkyDance, Вы писали:
SD>Вот, как ни странно, я с высоты нынешнего опыта, наверное, посоветовал бы не повторять мой путь. Ну да, я неслабо так почесал своё эго в итоге. Прокачал скиллы на предмет составления всяких бумаг, планов, прогнозов, учётов и т.п. Но кроме морального злорадства ничего не получил. А вот нервов потерял предостаточно — и овертаймов отсидел выше крыши. Если у вас действительно предапокалиптическая ситуация, то я присоединюсь к рекомендацияю Vzhik оглянуться по сторонам на предмет других контор поблизости. Даже если вы и не захотите никуда переходить, у вас хотя бы появится здоровый пофигизм на тему увольнения — это и нервы помогает сберечь, и уверенности придает (а уверенность — очень важный фактор при разговоре с любым начальством).
SD>Но ситуация у вас прямо классическая для российской разработки
Да-да, овертаймы, все дела.
Уже обновил резюме, насыпалось куча предложений прийти пообщаться, вздохнуть можно легче. Теперь буду более скурпулезно подходить к выбору проектов и менеджмента. Самому конечно хочется стать лидом, но нужны ещё скиллы в разработке, не верю я что можно адекватно менеджерить, если сам хотя бы до серьера не дорос.
V>Если у этого лидера есть голова, то он прежде подумает, чем брать на V>себе не понять что.
Это само собой. Но если проект действительно нужен конторе (косвенный признак — увеличение денежных расходов и внимания начальства), то даже при плохой ситуации можно его исправить. А если видно, что начальство, напротив, уводит людей и бюджеты с проекта (понятно, что крайне незаметно, чтобы не создавать панику), то тут все просто, надо уходить.
V>Опущу, все что ты написал. По сути вопрос: Добился ты того, чего хотел в V>результате этих разборок?
На первой итерации добился — неграмотного "начальника" убрали. Поставили куда более грамотного. Это была большая победа и проект пошел намного лучше.
V>Я предполагаю, что понырять в бочки с Г. не было твоей целью.
Целью (я тогда был моложе и бездетнее) было участие в хорошем проекте и выход интересного и полезного продукта, который бы на равных конкурировал с самым известным и раскрученным конкурентом. В общем-то, у нас тогда был реальный шанс превзойти тех самых конкурентов и стать первыми в мире в этой ОЧЕНЬ прибыльной области софтостроения (которая только сейчас начинает входить в массы — а мы делали это 5 лет назад). Я искренне в это верил и до сих пор верю, если бы тогда руководство хоть сколько-то внимания уделяло умным коллегам — сейчас бы компания стоила много больше (хотя и так компания большая). Да и я мог бы заработать на обещаный в те годы "домик в Вёшках" (С).
V>А где объявы? Планируете ли в Беларуси? Где планируете людей набирать?
Да какая Белоруссия, Новая Зеландия и Индия
А набирать, само собой, в Австралии, где я сейчас.
_>Теперь буду более скурпулезно подходить к выбору проектов и менеджмента.
Отрицательный опыт тоже опыт. Одна сложность, в России вообще тяжко с адекватным менеджментом. Но я с таким встречался — причем даже в одной очень большой компании. Не рискну ее рекламировать публично, но у меня о ней остались самые лучше воспоминания.
_>Самому конечно хочется стать лидом, но нужны ещё скиллы в разработке, не верю я что можно адекватно менеджерить, если сам хотя бы до серьера не дорос.
Бойтесь своих желаний, они сбываются.
Если хочется стать лидером "из-за денег" — лучше не надо, за деньгами правильнее просто уезжать из России (в США, Австралию, Канаду), оставаясь высококлассным программистом.
14.04.2011 18:00, michael_isu пишет:
> Уже обновил резюме, насыпалось куча предложений прийти пообщаться, > вздохнуть можно легче. Теперь буду более скурпулезно подходить к выбору > проектов и менеджмента. Самому конечно хочется стать лидом, но нужны ещё > скиллы в разработке, не верю я что можно адекватно менеджерить, если сам > хотя бы до серьера не дорос.
В нормальном менеджерении главное — работы с людьми (выше- и
нижестоящими), профессиональные скилы вторичны. При правильном вашем
подходе ваши подчиненные сделают все сами.
Здравствуйте, AlexNek, Вы писали: AN>Не думаю, что изучив десяток рецептов можно стать менеджером. Да и это может быть "опасно". Вот реальная ситуация, свидетелем которой я был. AN>Был один неплохой программист, сделавщий один несколько хороших проектов и пришла ему в голову идея другого проекта, но это проект ему было одному не потянуть и решило руководство сделать его ПМ-ом и дать ему команду. При этом теоретические знания о руководстве проектом у него имелись в достатке. Поначалу шло вроде неплохо, отчеты об этапах были радужные, планы — Наполеоновские, но потом всем потихоньку стало понятно, что проект "буксует", уже было хотели его даже уволить, но потом приняли более компромиссное решение. Нашли "старого" ПМ-а имеющего большой опыт в других (не программных) проектах, а этого просто "перевели" в члены команды. В итоге проект "ожил" и видимо будет успешно "сдан".
Просто интересно, что имеется в виду под "сделавший один"? Имеется в виду, что их было двое и ПМ руководил программистом? Такое бывает?
Здравствуйте, jeeist, Вы писали:
J>Здравствуйте, AlexNek, Вы писали: AN>>Не думаю, что изучив десяток рецептов можно стать менеджером. Да и это может быть "опасно". Вот реальная ситуация, свидетелем которой я был. AN>>Был один неплохой программист, сделавщий один несколько хороших проектов и пришла ему в голову идея другого проекта, но это проект ему было одному не потянуть и решило руководство сделать его ПМ-ом и дать ему команду. При этом теоретические знания о руководстве проектом у него имелись в достатке. Поначалу шло вроде неплохо, отчеты об этапах были радужные, планы — Наполеоновские, но потом всем потихоньку стало понятно, что проект "буксует", уже было хотели его даже уволить, но потом приняли более компромиссное решение. Нашли "старого" ПМ-а имеющего большой опыт в других (не программных) проектах, а этого просто "перевели" в члены команды. В итоге проект "ожил" и видимо будет успешно "сдан".
J>Просто интересно, что имеется в виду под "сделавший один"? Имеется в виду, что их было двое и ПМ руководил программистом? Такое бывает?
Нет, имеется в виду, что кроме этого программиста был только заказчик. Отчего требуется еще и руководитель?
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, jeeist, Вы писали:
J>>Здравствуйте, AlexNek, Вы писали: AN>>>Не думаю, что изучив десяток рецептов можно стать менеджером. Да и это может быть "опасно". Вот реальная ситуация, свидетелем которой я был. AN>>>Был один неплохой программист, сделавщий один несколько хороших проектов и пришла ему в голову идея другого проекта, но это проект ему было одному не потянуть и решило руководство сделать его ПМ-ом и дать ему команду. При этом теоретические знания о руководстве проектом у него имелись в достатке. Поначалу шло вроде неплохо, отчеты об этапах были радужные, планы — Наполеоновские, но потом всем потихоньку стало понятно, что проект "буксует", уже было хотели его даже уволить, но потом приняли более компромиссное решение. Нашли "старого" ПМ-а имеющего большой опыт в других (не программных) проектах, а этого просто "перевели" в члены команды. В итоге проект "ожил" и видимо будет успешно "сдан".
J>>Просто интересно, что имеется в виду под "сделавший один"? Имеется в виду, что их было двое и ПМ руководил программистом? Такое бывает? AN>Нет, имеется в виду, что кроме этого программиста был только заказчик. Отчего требуется еще и руководитель?
Тем более. Я тоже сталкивался с такими проектами, но почему-то думал, что такие бывают в местах, где о серьезной разработке речь не идет. Оказывается, это не так.
Здравствуйте, jeeist, Вы писали:
j> AN>>>Не думаю, что изучив десяток рецептов можно стать менеджером. Да и это может быть "опасно". Вот реальная ситуация, свидетелем которой я был. j> AN>>>Был один неплохой программист, сделавщий один несколько хороших проектов и пришла ему в голову идея другого проекта, но это проект ему было одному не потянуть и решило руководство сделать его ПМ-ом и дать ему команду. При этом теоретические знания о руководстве проектом у него имелись в достатке. Поначалу шло вроде неплохо, отчеты об этапах были радужные, планы — Наполеоновские, но потом всем потихоньку стало понятно, что проект "буксует", уже было хотели его даже уволить, но потом приняли более компромиссное решение. Нашли "старого" ПМ-а имеющего большой опыт в других (не программных) проектах, а этого просто "перевели" в члены команды. В итоге проект "ожил" и видимо будет успешно "сдан".
j> J>>Просто интересно, что имеется в виду под "сделавший один"? Имеется в виду, что их было двое и ПМ руководил программистом? Такое бывает?
j> AN>Нет, имеется в виду, что кроме этого программиста был только заказчик. Отчего требуется еще и руководитель?
j> Тем более. Я тоже сталкивался с такими проектами, но почему-то думал, что такие бывают в местах, где о серьезной разработке речь не идет. Оказывается, это не так.
Что то я не совсем понял Вашу мысль. Проблема просто в конкретном человеке, он довольно хороший исполнитель, но в менеджеры не годится.
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
Была у меня такая проблема.
Самое непонятное в этой ситуации — то ли он действительно с проблемой серьезной столкнулся, то ли тупит, то ли под видом проблемы пытается скрыть свое расп***яйство.
Решал просто — 160 часов, это 20 ч.д.
3 раза в день разработчик пишет детальный отчет — что сделано/не сделано, чем занят в данный момент, что планирует сделать (а не делать!) в ближайшие 4 часа, какие проблемы/ошибки/препятствия возникли. Мониторишь отчеты несколько дней — если видишь идет пробуксовка, подключаешься сам (если хватает квалификации), либо подключаешь кого-либо в помошь, кто может решить конкретный затык.
В общем, нужно усилить обратную связь.
AN>Нормальный менеджер спрашивает, что нужно что бы закончить вовремя. AN>И на подобные вопросы не отвечают — не знаю. Надо объяснить проблему, чем сложнее объяснение, тем лучше
Интересно, объяснение "хочу в отпуск!" прокатит?
Как корректно донести информацию о том, что трудоспособность ниже плинтуса и уже все настолько обрыдло, что мозг отказывается выполнять свою функцию. Но по плану — отпуск, только через месяц, например, потому что семья и все такое. А работать невозможно уже сейчас %)
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, michael_isu,
V_S>Тебе уже дали в ветке целую кучу полезных советов коллеги Геннадий Васильев, AlexNek, Gaperton...
Жаль только в постскриптуме к советам нет названия компании автора. Знать куда слать резюме слать в первую очередь
Здравствуйте, oziro, Вы писали:
O>Здравствуйте, AlexNek, Вы писали:
AN>>Нормальный менеджер спрашивает, что нужно что бы закончить вовремя. AN>>И на подобные вопросы не отвечают — не знаю. Надо объяснить проблему, чем сложнее объяснение, тем лучше
O>Интересно, объяснение "хочу в отпуск!" прокатит?
Ну если при этом получится закончить вовремя, то почему и нет. Хотя не уверен, что многие руководители будут с этим согласны.
O>Как корректно донести информацию о том, что трудоспособность ниже плинтуса и уже все настолько обрыдло, что мозг отказывается выполнять свою функцию. Но по плану — отпуск, только через месяц, например, потому что семья и все такое. А работать невозможно уже сейчас %)
В этом случае в данной фирме (рабочем месте), не имеет смысла больше работать.
По крайней мере, мне еще ни разу не приходилось слышать о подобной формулировке. Чаще наоборот встречаешся с тем что народ необходимо выгнать в отпуск иначе дни отпуска или переработки просто пропадут.
Хотя могут быть конечно различные личные проблемы.
Здравствуйте, JazzzMaster, Вы писали:
JM>Здравствуйте, michael_isu, Вы писали:
_>>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
JM>3 раза в день разработчик пишет детальный отчет — что сделано/не сделано, чем занят в данный момент, что планирует сделать (а не делать!) в ближайшие 4 часа, какие проблемы/ошибки/препятствия возникли.
И что кто то соглашался? Я бы послал немедленно, ну или по крайней мере попросил бы выбрать или работа или отчеты.
Здравствуйте, vb-develop, Вы писали:
VD>Здравствуйте, Vlad_SP, Вы писали:
V_S>>Здравствуйте, michael_isu,
V_S>>Тебе уже дали в ветке целую кучу полезных советов коллеги Геннадий Васильев, AlexNek, Gaperton...
VD>Жаль только в постскриптуме к советам нет названия компании автора. Знать куда слать резюме слать в первую очередь
Как правило, компаниям с малой текучкой относительно редко нужны новые люди.
Здравствуйте, SkyDance, Вы писали:
VD>>Жаль только в постскриптуме к советам нет названия компании автора. Знать куда слать резюме слать в первую очередь
SD>Э, тут не надо путать то, как авторы считают правильным, и то, как в компаниях происходит на самом деле.
Компания состоит не из людей, роботы чтоли решения принимают?
Мне достаточно того, что я буду работать с адекватными людьми, которые видят проблемы и понимают пути их решения.
Здравствуйте, SkyDance, Вы писали:
AN>>Как правило, компаниям с малой текучкой относительно редко нужны новые люди.
SD>Это значит, что компания маленькая, не растёт и не развивается -> роста зарплат тоже нет. Идти туда не надо.
У меня конечно нет полной статиститики, могу судить только об окружающих людях (и не только в одной фирме). И наблюдение показывает несколько противоположную картину.
А рост зарплаты это вообще отдельная тема.
Здравствуйте, Tilir, Вы писали:
T>Здравствуйте, AlexNek, Вы писали:
AN>>И что кто то соглашался? Я бы послал немедленно, ну или по крайней мере попросил бы выбрать или работа или отчеты.
T>Спорный вопрос.
Однозначные ответы бывают достаточно редко. T>Мне вот, например, нравится писать начальству насыщенные подробностями недельные отчёты,
Тяжело оценить время, ну скажем раз в неделю 1 час. При этом время можно выбрать относительно произвольно.
Скажем отчет поменьше ну минут 15, что бы не с потолка все брать. 3 раза в день почти час, пять раз в неделю, почти рабочий день. При этом нужно все время смотреть на часы чтобы не проспать с отчетом, а после переключаться работа/отчет и назад. T> систематизируя и приводя таким образом в порядок всё, чем я занят, в первую очередь у себя в голове. При этом читают их или нет, мне пофиг. Это как рассказать всё воображаемому другу. Только лучше. Так что может и действительно сработало. Я вот, если закапываюсь, делаю свои сеансы бесед с воображаемыми коллегами несколько чаще, у меня к счастью есть отдельная доска с маркерами и я на ней рисую, обсуждаю за двух-трёх человек одновременно и многое таким образом решается.
У каждого свой способ мышления, но ваш мне еще не попадался, по крайней мере в среде программистов мне еще не попадался человек, кому бы нравилось писать какие либо бумажки регулярно.
SD>>Э, тут не надо путать то, как авторы считают правильным, и то, как в компаниях происходит на самом деле.
VD>Компания состоит не из людей, роботы чтоли решения принимают? VD>Мне достаточно того, что я буду работать с адекватными людьми, которые видят проблемы и понимают пути их решения.
Вы определенно не представляете себе работу менеджмента. Попробую пояснить, в упрощенном варианте.
Есть менеджеры среднего звена. Те самые "проджект менеджеры". Или их "заменители" — позиции могут называться по-разному. Они все прекрасно понимают — они догадываются, что писать отчёты по 3 раза на дню разработчики не очень мечтают. Но! Над ним тоже есть свои "менеджеры". Которые требуют оных отчетов. Что делать? В 99% случаев тот самый "средний менеджер" станет объяснять команде, что это не его большое желание иметь эти отчёты. Придумают с командой какой-нибудь компромисс.
Короче. То, что в компании есть один (или несколько) людей, которые пишут умные, правильные и грамотные вещи на форуме — вовсе не означает, что по приходу и реальному трудоустройству в компании не окажется, что на самом деле там "забыли" про отчёты, которые требует начальство. Тут "забыли" про формальный тест по С++ (ау, Акронис, вы все еще делаете это безумие на 20 страницах с вопросами "что из перечисленного не является контейнером STL?"). В каком-то еще пункте конкретный менеджер может быть не согласен с общей политикой компании.
В общем, то, что *хочет видеть* один отдельный человек в компании, и то, как в ней *на самом деле работается* — две совершенно разные независимые вещи. Всё в том же Акронисе можно побеседовать с парой очень интересных людей — и подумать — ё-маё, а классно-то как, надо туда! А можно и на "тестирование знаний по С++" нарваться...
Здравствуйте, SkyDance, Вы писали:
SD>>>Э, тут не надо путать то, как авторы считают правильным, и то, как в компаниях происходит на самом деле.
VD>>Компания состоит не из людей, роботы чтоли решения принимают? VD>>Мне достаточно того, что я буду работать с адекватными людьми, которые видят проблемы и понимают пути их решения.
SD>Вы определенно не представляете себе работу менеджмента. Попробую пояснить, в упрощенном варианте. SD>Есть менеджеры среднего звена. Те самые "проджект менеджеры". Или их "заменители" — позиции могут называться по-разному. Они все прекрасно понимают — они догадываются, что писать отчёты по 3 раза на дню разработчики не очень мечтают. Но! Над ним тоже есть свои "менеджеры". Которые требуют оных отчетов. Что делать? В 99% случаев тот самый "средний менеджер" станет объяснять команде, что это не его большое желание иметь эти отчёты. Придумают с командой какой-нибудь компромисс.
Не представляю компанию в которой топ-менеджерам и прочим директорам интересны отчеты от программеров по три раза на дню. Чаще всего их требуют те менеджеры, которые сами очень формально подходят к своей работе. Им сверху спустили указание, они не сильно напрягая голову потребовали реализации от подчиненных. Вместо того, чтобы немного подумать и попросить от людей сделать ровно ту работу, которая будет полезна и для самих сотрудников, и для линейного руководителя, и для более высокого начальства.
Я не говорю, что компания окажется обязательно хорошей. Но есть вероятность (скорее мат. ожидание) что в этом случае твоим руководителем не будет человек, случайно попавший на эту должность, или считающий что работа начальника это когда платят больше, а делать нужно меньше.
Здравствуйте, SkyDance, Вы писали:
VD>>Я не говорю, что компания окажется обязательно хорошей. Но есть вероятность (скорее мат. ожидание) что в этом случае твоим руководителем не будет человек, случайно попавший на эту должность, или считающий что работа начальника это когда платят больше, а делать нужно меньше.
SD>Чего ж вторую-то часть (в которой суть сосредоточена) цитировать не стали? Мне еще раз ее привести? Так без проблем. Повторяю: даже если менеджер понимает и знает, как _должно быть_, или как _ему_бы_хотелось_ — это не значит, что именно так оно и будет в конторе.
С этим можно скорее согласится, чем возражать. Однако я бы ввел понятия: философия/стиль работы компании и умность менеджера.
С "умным" менеджером почти всегда будет хорошо работаться.
А стиль работы компании, практически невозможно изменить парой "умных" менеджеров внизу цепочки. SD>Один, два, даже пять грамотных товарищей влёгкую потонут в сотне "обычных".
Вообще то, мне кажется, проекту даже противопаказано иметь много "грамотных товарищей". Всегда полно работы, которую им нежелательно поручать, ну типа побелить стены во всем доме. SD>И никто этих грамотных товарищей слушать не станет (традиционная беда России, кстати, — каждый начальник всегда считает себя умнее всех остальных, и не слушает тех, кто под ним, потому что они by default его глупее).
Это я бы отнес в раздел стиля работы фирмы.
Как то был в компании где было нежелательно высказывать вообще любую критику.
А сейчас, могу спокойно сказать шефу что его идея фигня, как и он мне.
Бывало часами спорили, зато потом находилась гораздо лучшая идея.
AN>С этим можно скорее согласится, чем возражать. Однако я бы ввел понятия: философия/стиль работы компании и умность менеджера. AN>С "умным" менеджером почти всегда будет хорошо работаться.
Вне всякого сомнения! Особенно если кавычки от слова "умный" убрать, а то как-то двусмысленно уж очень. Вот только даже самый что ни на есть хороший менеджер из конторы вылетит, если не будет соответствовать принятым (более высокими, но не факт что столь же хорошими) менеджерами правилам.
AN>А стиль работы компании, практически невозможно изменить парой "умных" менеджеров внизу цепочки.
Я про то и написал. То, что пара человек пишут хорошие и правильные вещи на форуме, никак не говорит о том, что происходит в компании, где они работают.
AN>Бывало часами спорили, зато потом находилась гораздо лучшая идея.
Видать, у вашего шефа слишком дофига свободного времени.
Здравствуйте, SkyDance, Вы писали:
AN>> Если этапы сдаются в срок и не слышно "криков" из команды, то как работает менеджер "внизу" руководству должно быть по барабану.
SD>Это в теории. А на практике, руководству очень часто хочется "чего-нибудь поруководить". Особенно если это какое-нибудь очередное промежуточное руководство, еще одна прослойка ненужных менеджеров.
Пока еще не попадались SD>В России обычно и вовсе важно не то, как "этапы сдаются в срок", а то, кто с кем учился, в бане парился и по девкам бегал.
Про Россию могу только догадываться.
SD>>>Видать, у вашего шефа слишком дофига свободного времени. AN>>Как раз нпоборот.
SD>Было бы как раз наоборот — шеф бы задавал приоритеты, а не сам лез в технические детали.
По крайней мере, нужен человек хорошо знающий конкретные детали.
Сейчас, кстати, он просто член команды, а раньше был ПМ и и как бы архитектор системы. Страшно любит плодить что то в УМЛ, раньше были все стены и шкафы завешаны распечатками.
AN>>Еще полезно просто рассказать о решении коллегам.
SD>А вот с коллегами вы некрасиво поступаете — "рассказываете о решении". Очень некрасиво выглядит, будто вы там с шефом интриги ведете, и вообще "оторвались от коллектива".
Возможно по тексту выходит, что вначале идет разговор к шефом, а после с коллегами.
Я же имел в виду, что любую идею полезно просто кому то рассказать. SD>Понимаю, что, видимо, вы так ведёте свой карьерный рост (традиционно, кстати, для российских "манагеров"), но команде это всегда не нравится.
Вообще то аборигены обычно не ставят туземцев выше себя. SD>Вы должны с коллегами обсуждать решение, а боссу его "просто рассказывать".
Не всегда можно стричь под одну гребенку.
"Ах вы так, значит". Я говорил о странах Россия и Москва. Причем неоднократно это упоминал. В США и Австралии подход к руководству отличается от принятого в России (да и вообще уж очень отличается от конторы к конторе).
AN>Сейчас, кстати, он просто член команды, а раньше был ПМ и и как бы архитектор системы. Страшно любит плодить что то в УМЛ, раньше были все стены и шкафы завешаны распечатками.
Тогда так и надо было писать, не "шеф", а "член команды, с которым я советуюсь".
AN>Возможно по тексту выходит, что вначале идет разговор к шефом, а после с коллегами.
Именно так я вас и понял. Если ошибся — извините. Но впредь урок точнее объяснять процессы.
SD>>Вы должны с коллегами обсуждать решение, а боссу его "просто рассказывать". AN>Не всегда можно стричь под одну гребенку.
Т.е. вы все-таки настаиваете на том, что вы придумаываете решение, обсуждаете его с боссом (который, почему-то, уже не босс, а член команды), и потом объявляете коллегам? Или что? Я, простите, запутался. Поясните на конкретном примере, может, мне проще будет понять.
Здравствуйте, SkyDance, Вы писали:
AN>>Сейчас, кстати, он просто член команды, а раньше был ПМ и и как бы архитектор системы. Страшно любит плодить что то в УМЛ, раньше были все стены и шкафы завешаны распечатками.
SD>Тогда так и надо было писать, не "шеф", а "член команды, с которым я советуюсь".
Там шла речь именно о "периоде шефа".
AN>>Возможно по тексту выходит, что вначале идет разговор к шефом, а после с коллегами.
SD>Именно так я вас и понял. Если ошибся — извините. Но впредь урок точнее объяснять процессы.
Я бы не стал ожидать однозначного истолкования текста на форуме, тут и в статье не всегда получается усмотреть все ньюансы. Если есть недопонимание, проще и быстрее обсудить на этом же форуме.
SD>>>Вы должны с коллегами обсуждать решение, а боссу его "просто рассказывать". AN>>Не всегда можно стричь под одну гребенку.
SD>Т.е. вы все-таки настаиваете на том, что вы придумаываете решение, обсуждаете его с боссом (который, почему-то, уже не босс, а член команды), и потом объявляете коллегам?
Где это было написано? Не нужно обобщать, и додумывать то что не требуется. SD>Или что? Я, простите, запутался. Поясните на конкретном примере, может, мне проще будет понять.
Прежде всего есть две точки отсчета, один пример и одна рекомендация.
Пример был для точки отсчета 1 в прошлом, когда упомянутый человек был ПМ. В точке отсчета 2, в настоящее время, данный человек уже не ПМ.
Рекомендация рассказать идею кому либо, абсолютно самостоятельна и не имеет никакой связи с примером.
Просто когда пытаешся что то рассказать, может происходить некоторое переосмысливание проблемы и решения.
Однако обсуждать следует только действительно проблемы.
А то вот сегодня дернул меня черт произнести "умную фразу" — "асинхронный старт второго треда" и погряз на пару часов доказательств о "нафига оно надо", зачем усложнять и т.п.
А вообще многое зависит от конкретики. Конкретная фирма, конкретный проект, конкретная команда, конкретная ситуация.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, SkyDance, Вы писали:
SD>>Вместо того, чтобы просто сказать "а, не надо тут ничего сложного" и потратить 2 часа на полезное дело,
U>А если тут надо сложного? Тогда что делать?
Вообще то все относительно. Если при слове тред и синхронизация бегут мурашки по коже, то сложно.
А проблема довольно простая (которая, кстати, не относится к теме форума): как при успешном окончании треда запустить новый?
Здравствуйте, AlexNek, Вы писали:
AN>Вообще то все относительно. Если при слове тред и синхронизация бегут мурашки по коже, то сложно. AN>А проблема довольно простая (которая, кстати, не относится к теме форума): как при успешном окончании треда запустить новый?
В данном контексте не важно, что обсуждалось. SkyDance же утверждает, что вообще не существует ситуаций, в которых подчиненный должен обсуждать проблему с начальником. Непонятно только зачем начальнику нужны подчиненные, которые его не поправят в случае ошибочного решения. ЧСВ чесать что ли?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, AlexNek, Вы писали:
AN>>Вообще то все относительно. Если при слове тред и синхронизация бегут мурашки по коже, то сложно. AN>>А проблема довольно простая (которая, кстати, не относится к теме форума): как при успешном окончании треда запустить новый?
U>В данном контексте не важно, что обсуждалось. SkyDance же утверждает, что вообще не существует ситуаций, в которых подчиненный должен обсуждать проблему с начальником.
Такого четкого утверждения я не заметил. Но вообще ... It depends ...
Отклонения от 0 до 100% вполне возможны. U>Непонятно только зачем начальнику нужны подчиненные, которые его не поправят в случае ошибочного решения.
Все бывает. Часто нужны просто роботы.
Хотя мне кажется, есть неплохая стратегия, для подобного случая.
В подходящее время, в подходящей форме просто высказывается свое мнение, без какого либо противопоставления. Если его никто не заметил, о нем можно забыть.
U>SkyDance же утверждает, что вообще не существует ситуаций, в которых подчиненный должен обсуждать проблему с начальником.
Не надо перевирать, пожалуйста. С начальником можно обсуждать что угодно, но предварительно следует достичь консенсуса со своими коллегами. ДО того, как идти с решением к начальнику. А если в одиночку идти к начальнику, с ним "решать", а потом "объяснять" коллегам — получите неприятный эффект. Я знаю, по молодости и глупости проверял.
Здравствуйте, SkyDance, Вы писали:
U>>SkyDance же утверждает, что вообще не существует ситуаций, в которых подчиненный должен обсуждать проблему с начальником.
SD>Не надо перевирать, пожалуйста. С начальником можно обсуждать что угодно, но предварительно следует достичь консенсуса со своими коллегами. ДО того, как идти с решением к начальнику. А если в одиночку идти к начальнику, с ним "решать", а потом "объяснять" коллегам — получите неприятный эффект. Я знаю, по молодости и глупости проверял.
Коллеги здесь вообще причем? О них речи вообще не было. Началось все с утверждения AlexNek, что спор подчиненного с начальником это совершенно нормальное, а часто и вовсе необходимое для дела явление http://rsdn.ru/forum/management/4353564.1.aspx
Здравствуйте, SkyDance, Вы писали:
U>>SkyDance же утверждает, что вообще не существует ситуаций, в которых подчиненный должен обсуждать проблему с начальником.
SD>Не надо перевирать, пожалуйста. SD>С начальником можно обсуждать что угодно, но предварительно следует достичь консенсуса со своими коллегами.
Консенсуса о чем? Нужно ведь хотя бы тему знать до того как. SD> ДО того, как идти с решением к начальнику.
Мне кажется, вы пытаетесь свою ситуацию точно отобразить на представленную. Между тем, как мне кажется, что они в корне различны. И вообще, думаю, будет полезней обсуждать ситуации, а не личности их описавшие.
Во первых, к начальнику (о котором была речь) идти не нужно, он сидит за соседним столом. Во вторых, как можно обсуждать с коллегами, то чего еще нет или то, что вы сейчас делаете или просто обдумываете как сделать? SD>А если в одиночку идти к начальнику, с ним "решать", а потом "объяснять" коллегам — получите неприятный эффект. Я знаю, по молодости и глупости проверял.
Даже если сделать именно так, то опять таки все зависит от конкретной ситуции. Иногда бывает достачно просто увидеть, что кто то зашел к шефу, что бы относится к нему с большой осторожностью. А иногда просто необходимо пойти к шефу. И опять таки, еще нужно определится с понятиями начальник, шеф, ПМ, ПЛ. Вполне вероятно что мы вкладываем в них различный смысл. Ну например и ПМ и ПЛ мне подходят под понятия начальник и шеф.
Ну или допустим, одни делают GUI, а другие обвертку к базе. Если и те и другие обеспечивают принятый интерфейс, то каждой группе должно быть "глубоко наплевать" как реализуется другая часть.
При этом возможно представить ситуацию, когда желательно точно наоборот. Это я к тому что описываемые мной ситуации не догма, а просто мое личное мнение о большей вероятости появления описываемой ситуации в моем окружении.
Здравствуйте, michael_isu, Вы писали:
_>Допустим ситуация такая: разработчику поручено реализовать какой-то модуль, трудозатраты в целом на него — 160 часов. Все это разбито на задачи длительностью от 1 до 16 часов. Но вот какая-то задача у него затягивается, объяснения этого не пустые, но достаточно размытые, человек несколько раз откладывает сроки закрытия задачи. Каковы ваши действия в такой ситуации? Ожидать завершения задачи? Если вмешаться, то как?
? Проще с ним поговорить.
)
