Comments 82
Я тоже в первый раз как то мимо заголовка прочитал. Потому что увидел глазом, щёлкнул. А на новой вкладке из-за хабраката заголовок уже не виден.
Это было бы забавно, если бы не было правдой. Читал и видел своего босса и менеджера…
На самом деле потом, когда такой босс становится бывшим, над этим действительно можно поржать и даже с некоторым удовольствием вспомнить.
Ахахаха! Спасибо! Напомнило бывшего коллегу. Настолько следовал этим правилам, что за 4 месяца работы сумел разрушить наработанный отдел, существовашший год. Молодец-парень! Кремень, а не мужик! Настолько всех приводил в «отличное» расположение духа, что с переездом в офис на 9-м этаже стал бояться с нами выходить на балкон курить. Спасибо автару. От души посмеялся, ну и для себя сделал кое-какие выводы и посмотрел, так сказать, со стороны.
Сто процентов это уже где-то читал в переводе. На хабре точно было.
UFO landed and left these words here
ага, этакая торговля во время оглашения сроков.
— Сделаю за неделю.
— Да, а почему так долго? Получится за полнедели?
— Нуу, вряд ли, тут же такое дело…
— Ну постарайся, очень уж надо за три дня.
… и на эти три дня отправить разработку на другой, «горящий», проект

А вот это логично — чтоб была потом отмазка почему не уложились…
У меня было:
— Сколько нужно времени?
— Минимум 2 месяца, в идеале 3.
— Давай за два
— Хорошо, но будет сыровато и скорее всего с мелкими багами.
— Всё нормально, потом доправиш на продакшене.
… прошло два дня…
— Запустить нужно через 3 недели!
— Ээээ. Какие три недели? Минимум два месяца.
— Ничего не знаю, мы вчера уже рекламу в журналах и на ТВ заказали да оплатили. Плюс презентацию так же оплатили и разослали приглашения.
— Вот заявление, удачи вам...
Кстати, есть обратная сторона медали. Один менеджер рассказывал (дословно не помню, но примерно так). Даешь 3 дня — делают за неделю, даешь неделю на задание — делают за 2, говоришь кровь с носа нужно на завтра — на завтра все готово :)
Ну для этого давным давно уже придумана система мотиваций. Ведь легко можно предложить за ранние сроки дать отдельную премию. И тогда действительно будет желание посидеть и в выходной и ночью. А без мотиваций, как в мультике про купца и 40 шапок из одной шкуры. Да, сделают быстро, но то что это будет работать и работать хорошо, большой вопрос. Ведь могут и «на зло» множество косяков оставить, чтобы потом сказать «ну я же говорил». :-)
Опять же обратная сторона: шантаж на получение премии — завысить сроки, а сделать реально быстро.
Про то, что потом на поддержку и исправление этого «завтрашнего» говнокода будет потрачено ещё *дцать человеко-месяцев, менеджер не думает, ага.
иногда реализация говнокода сейчас важнее, чем реализация по феншую, но потом.
Что значит даешь? Разве не задача менеджера побить задачу на минимальные блоки и уже исходи из суммарного времени оценивать задачу. Минимальный блок в 2 дня не принимается, потому что есть стандартный рабочий день 8 часов. И то 8 часов как минимальный блок это крайний вариант.
Ну я передал как вспомнил. Этот человек был из украинского центра разработки… ну в общем, всем известной всемирной компании. Уточнять не буду :)
На вопрос «когда нужно?» всегда отвечайте «вчера»

Просто интересуюсь: а формулировка «Чем раньше, тем лучше» тоже подходит под это правило? Меня всегда вымораживает, когда не могут назвать сроки, пусть даже примерные, но обозначенные.
Это со мной что-то не так?
Разработчики, судя по моему опыту, гораздо лучше воспринимают когда задачи идут одна за другой, а не по датам.
Т.е. навопрос «на когда нужно» лучше отвечать: «в первую очередь». Да, он все равно может сказать: «Так у меня же других полно», но тут уже можно возразить «Брось все и делай эту».
Хотя, такая постановка задач все равно бесит. Кучу всего бросать недоделанным и переходить к новому — неприятно. А потомсиди вспоминай, на каком месте бросил.

А про оценку задач можно вообще долго дискутировать. Тут и сторипоинты придумывают, и «помидоры» с «бананами».
Я считаю, что если команда с часами или днями работать не может, то как раз ПМ должен предложить адекватную систему оценки и потом сам переводить ее в дни.
Чисто для меня важен срок, потому что я понимаю, что в конце этого срока от меня ожидают как-то готовый функционал. Ключевое слово готовый. Соответственно, в зависимости от срока выделенного на этот функционал я могу разбить его на определенное количество под-задач. И от того, сколько у меня времени я решаю чем я могу пожертвовать в угоду скорости.
Так что если нет сроков, то просыпается внутренний идеалист, который старается сделать этот функционал как можно более правильно. Соответственно сроки работы вырастают.
Хотя скорее всего дело в небольшом опыте.
Всё так.
Вы не сталкивались с этим видом работ или объем работ обширен и разнообразен.
Чтобы пофиксить проблему нужно отвечать так: «мне надо 2 часа, чтобы подумать над списком задач и оценить примерные сроки».
Потом составить этот план, разбив всё на подзадачи. Добавить всякие непредвиденные овертаймы, добавить время на переговоры, совещания, задержки и выкатить примерные сроки мин-макс. Уверяю, что переделать таблицу на «без перезагрузки», т.е. с аяксом, потребуется на 2 дня, а 5 и это будет реальные 5 дней, а не 2 + ой ещё 2 + ой не успеваю, ещё день.
Первые три — так точно был уверен что это правила для менеджера.
Да, хороший пост, может, хоть кто-то себя хоть приближенно увидит и сделает выводы, но есть одно у меня замечание:
вокруг — взрослые и серьезные люди.

Если всегда держать в уме, что не все взрослые и не серьезные и относиться к ним также — они никогда не станут взрослым и серьезными, по крайней мере, под вашим началом. Не взрослый и не серьезный должен это осознать и начать работать над собой, как минимум.
Страдаю часто 1-й, постоянно — 6-й и изредка — 10-й из описаных проблем…
О да, 6-я — это мое проклятье, никак не могу из себя вытравить. 10-я тоже бывает.

А по срокам я обычно делаю так. Спрашиваю у исполнителя, сколько надо времени, умножаю ответ на 1,5-2, и уже этот срок сообщаю заказчику (или вышестоящему руководству). Если никаких форс-мажоров не происходит, то все рады тому, что работа выполнена раньше. Зато если что-то идет не так, то никакой истерики вокруг просрочки нету.
Методы хороши и действенны, но уж больно попахивает большой текучкой разработчиков.
Справедливости ради надо сказать, что не всегда менеджер виноват в применении какого-то из этих правил. Часто его принуждают к этому обстоятельства, Например, в виде вышестоящего менеджера.
Нет. Меняет сроки на ходу, требует совещаний и названивает в выходные. Я же не про все пункты, а про некоторые.
Стыдно признаваться, но во многом узнаю себя. Хотя даже и не стыдно. Стыдно думать, что это все не про меня, что я офигенный управленец и сам все знаю. На самом деле так уж складываются обстоятельства, что мы становимся такими)) З.Ы.: Но мы над этим работаем.
Думал Ильдар(веду один проект сейчас и там он ПМ), проверил профиль, не, вы не с Челябинска и зовут вас не Ильдаром. :-)
КДПВ настолько великолепна, что прямо-таки просит сделать из нее целую серию демотиваторов!
В посте не хватает ещё иллюстраций в стиле «Вредные советы Г.Остера».
Кому интересна тема менеджеров советую почитать:
image
Мне кажется по этим правилам «работают» только в госкомпаниях, в особенности по последнему правилу.
В любых крупных, на самом деле. Особенно тех, у которых IT — это всего лишь часть бизнеса.
Вы слишком хорошего мнения о частниках.
Я шесть лет проработал в одной государственной структуре. Столько мрака повидал…
Сейчас я там на полставки болтаюсь ибо полноценно передать всё хозяйство да вырастить смену надо года два.
Так вот, самые страшные бумажные вопросы мой отдел по привычке отдает мне.
Я недавно подсчитал, что за последние пару месяцев у меня не было сложных ситуаций с бумагами по государственной линии.
А вот так, чтобы частники достали с бюрократией до мата — такое пару раз было. Матерился конечно не вслух, но не суть…
9 из 10… боже, 9 из 10. То есть тьфу, 10 из 12. А я-то думал мне только кажется, что на работе какая-то гуйня нездоровая происходит.
[humor]Мне всё время кажется, что со мной постоянно происходит какая-то нездоровая щуйня. Что самое странное и неприятное, что она меня никак не отпускает, несмотря на все мои старания и попытки. Нет, не подумайте плохого, я всего лишь программист.[/humor]
Насчёт «сделать самому» — иногда это сильно проще, чем проводить задачу через нескольких людей. При этом нужно знать меру и изменения должны быть понятными, это раз, и два, желательно сказать о них заинтересованным людям.

Я вполне серьёзно говорю, потому что иногда пойти и дописать пару строчек (под парой строчек я имею в виду не больше 30-40 символов без изменения логики программы) куда эффективнее, чем отвлекать людей на issue.
Абсолютно поддерживаю. Минусовал глупый человек без реального опыта проектной работы.
Сохраню в избранное, а лучше распечатаю. Не могу похвастать, что хоть раз не нарушал бы каждый из пунктов, а некоторые нарушаю постоянно — особенно про «вчера». Спасибо автору за мотиватор.
Насчёт пункта про «Делать всё самому»: плох тот менеджер, который хотя бы по верхам не представляет себе специфику работы специалистов.
Тут есть два полюса, на самом деле. Один полюс — это «менеджер из ниоткуда», когда над группой инженеров ставят менеджера, который специфику предметной области понимает плохо, зато зарекомендовал себя, как «хороший управленец». Такой товарищ опасен, в первую очередь, постройкой культа карго — он «что-то услышит» — и айда внедрять.

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

А истина традиционно посерединке.
Интересный текст, многое так, но не всегда. У меня руководителем был коммерческий директор одной крупной московской компании с 4 млн. клиентов. Планы особо не вел. Достаточно было ему периодически давать просто по электронной почте основные вехи. Сам мог работать — если была проблема, то засучивал рукава и влезал в проблему вплоть до мелочей. Под управлением было примерно 1000 человек. После его ухода впечатление у всех осталось крайне благоприятным. Планы по продажам всегда выполнял.

Сейчас живет в США, основал там стартап в области финансов.

Так что бывают менеджеры без диаграмм ганта, увлеченный, готовый работать до 11 вечера, способный на ходу менять план, если изменение позволит добиться лучшего результата. Я знаю таких двух.
Нет ничего плохого в том, чтобы менять план. Плохо — не иметь плана, хотя бы в виде вех.
В общем, да. Я и хотел сказать своим комментарием — что главное авторитет, харизма и профессионализм менеджера. А решает он проблемы диаграммами ганта, совещаниями или личными звонками — дело десятое.
План (в смысле, детальный), по-моему, нужен, чтобы избежать простоев и взаимных помех (да, и как в некоторой степени, математик, могу сказать, что их, как и все остальные накладки можно в итоге свести тоже к простоям;-) ). Если простои не грозят, то постройка плана не ускорит работу.
первый совет — хороший совет.
Ни разу в жизни не видел плана разработки, который не был бы похерен через несколько недель.
У нс сейчас идет крупный проект. По моим оценкам — завершен уже процентов на 70%. При этом бедный PM все еще проводит согласования в электронной системе документооборота, периодически что-то детализирует (там уже более 600 строк) :), а периодически все понимают, что реальное дело обогнало план-график, и нужно его глобально актуализировать. После этого цикл бессмысленных согласований начинается практически заново. :) Наблюдать за этим очень увлекательно.
«Как убить проект конкурентов? 12 правил шпиона-менеджера» :-)
обратная сторона «медали» )

12 правил плохого программиста.

1. Никогда не думай о бизнес-процессах, не читай про маркетинг, SEO. Писать код гораздо интереснее, чем понимать, зачем.
2. Постарайся не думать о приоритетах. Начинай делать ту задачу, которую тебе проще решить.
3. Если задачу делать не хочется — скажи, что это невозможно.
4. Не отвечай на скайп и почту, старайся игнорировать коллег.
5. Если просят добавить одну строчу текста — говори, что на уйдет минимум полдня. Все равно не смогут проверить.
6. Если сроки сорваны — сваливай все на плохую постановку, никогда не признавай своих ошибок.
7. Не вдумывайся в постановки — они все равно неправильно написаны.
8. Если задача поставлена менее, чем в брошюре на 24 листа — требуй подробного техзадания. Если у тебя есть техзадание — не читай его, это
не интересно.
9. Не называй сроков — как сделается, так сделается.
10. Старайся не расти профессионально, делай, как привык.
11. Не бери на себя ответственность, ты всего лишь исполнитель.
12. Работай с 9 до 18 — ни секундой больше. А лучше, приди попозже, а уйди пораньше.
а можно ответить?

1. А зачем? Писать код действительно интереснее, и зарплату платят не за маркетинг, и доли в компании все равно не дадут, так в чем тогда мотивация? Вот предметную область знать надо, но лишь для того чтобы проще было код писать.
2. палка о двух концах. Если время позволяет, хороший способ разогнаться в поток — взять простую интересную задачу и, выполнив ее, переключиться на сложную нудную.
3. всегда так делаю, грешен :) но я еще и объясню, почему нельзя. а если не смогу — придется делать :)
4. я бы скайп и вовсе выключал, кроме каких-то оговоренных часов. когда работаешь в потоке — все эти штуки ужасно мешают. отключился от всего — сделал задачу, открыл почту/скайп и ответил всем.
11,12. все верно. а в чем мой интерес поступать иначе?
интересная работа и возможность работать так как я хочу, хороший климат? ок, вот я уже и сам не заметил, что давно домой пора.
хороший бонус за сдачу проекта вовремя или раньше сроков? доля в компании? ок, я буду сидеть до победного и проверю чем занимаются остальные. помогу отстающим.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.adv.ru
Employees
51–100 employees
Registered