| Сегодня 3 июня, понедельник |
      |
  
|
  
Какой рейтинг вас больше интересует?
|
Главная /
Каталог блоговCтраница блогера PM-Jedi/Записи в блоге |
 |
|
Вредные советы руководителю проектов. Часть 2
2012-04-12 18:48:00 (читать в оригинале)В первой части "вредных советов" я объяснил, как надо правильно работать с планами, командой и заказчиком, чтобы успешно провалить проект. В этой части речь пойдёт о процессе разработки и тестирования.
Проектирование
Достаточно дать программисту "смутные мысли заказчика" на одном листке, чтобы через неделю ожидать готовой функциональности. Он же профессионал!Программисты всегда лучше, чем заказчик знают, как должно работать приложение. Они же его пишут. Кстати, требования тоже придуманы только для того, чтобы мешать программистам творить. Поэтому программисты должны смело писать так, как считают правильным, не оглядываясь на всякую бюрократию, вроде ТЗ.
Главное в ПО - это внутренняя красота, структура и код. Удобство использования придумали неудачники, которые не умеют программировать. Интерфейсы пользователя должны проектировать только программисты. Иначе как определить, что вписывается в красивую архитектуру системы, а какие фичи надо вычеркнуть. Ну действительно, не менять же из-за них эту замечательную диаграмму классов!Чем сложнее интерфейс пользователя, тем больше вашу команду будут уважать, как разработчиков "такой сложной системы".
Если программист сидит и не строчит по клавиатуре, значит он бездельничает и его надо наказать. Те, кто говорит, что, перед тем, как писать код, нужно подумать, – лодыри, которые не хотят работать. "Продумывание архитектуры" - это вечный повод ничего не делать и тратить бюджет проекта. Вы же не дом строите, чтобы задумываться об архитектуре.
Ни в коем случае не делайте прототипы. Вы потратите бюджет, а в результате получится непонятная и одноразовая поделка. Если вы, вдруг, уже написали прототип, ни в коем случае не выбрасывайте его. Ведь это почти готовое приложение. Представьте, сколько времени и ресурсов было на него потрачено! Если чуть-чуть доделать прототип, то вполне можно писать остальную систему на его основе.
Разработка
Никогда не забывайте, что вы разбираетесь в технологии лучше всех. Поэтому обязательно несколько раз в день вам надо ходить, читать код программистов и критиковать его. Достаточно сказать, что код, который написал программист – отстой. Ни в коем случае не говорите, почему, даже если знаете. Программист должен до всего доходить собственным умом – пусть подумает сам.
Лично просматривайте каждую строчку кода, написанного программистами. Пусть они знают, что вы им не доверяете, и любая ошибка, которую они допустят, будет вами найдена, а они – наказаны.
Ставить задачи программистом лучше всего устно. У вас и так нет времени, чтобы отвлекаться и детально описывать проблему, а у программистов память хорошая – запомнят. Кстати, чем больше задач на неделю программисту поставить, тем больше он сделает.
Обязательно обсуждайте с программистом возникшие вопросы сразу, как только вы про них вспомнили. Им ничего не стоит переключиться с текущей задачи на проект трёхлетней давности, а вы ведь можете и забыть, что хотели уточнить.
Не стоит давать сотруднику работать над одной задачей непрерывно более 15 минут. Переключите его на другую задачу, если видите, что он увлечённо работает. Высока вероятность, что он упорствует в ошибке, и потом придётся всё за ним переделывать. К тому же, переключение программиста между задачами способствует развитию внимания и краткосрочной памяти.
Контроль качества и ошибки
За каждую найденную ошибку надо давать тестировщику премию, вычитая её из зарплаты программиста. Впрочем, тестировщики на проекте вообще не нужны. Программисты могут тестировать свой код сами.Всячески поощряйте конфликты между тестировщиками и программистами. Тестировщики должны ненавидеть программистов. Тогда поиск ошибок становится для них ещё и личным делом, и они тестируют гораздо лучше.
Если в проекте найден баг, обязательно выясните, кто его допустил и прилюдно выскажите своё порицание провинившемуся программисту. Дайте понять не только ему, но и всей команде, что он непрофессионал. Настоящие профессионалы ошибок не совершают.
Нет смысла тестировать версию перед релизом. Это пустая трата проектного бюджета. Вы и так знаете, что профессиональные программисты ошибок не допускают.
Никогда не пишите юнит-тесты – это пустая трата ресурсов. Они значительно увеличивают сроки разработки, а в результате всё равно никто их не запускает.
Вредные советы руководителю проектов. Часть 2
2012-04-12 18:48:00 (читать в оригинале)В первой части "вредных советов" я объяснил, как надо правильно работать с планами, командой и заказчиком, чтобы успешно провалить проект. В этой части речь пойдёт о процессе разработки и тестирования.
Проектирование
Достаточно дать программисту "смутные мысли заказчика" на одном листке, чтобы через неделю ожидать готовой функциональности. Он же профессионал!Программисты всегда лучше, чем заказчик знают, как должно работать приложение. Они же его пишут. Кстати, требования тоже придуманы только для того, чтобы мешать программистам творить. Поэтому программисты должны смело писать так, как считают правильным, не оглядываясь на всякую бюрократию, вроде ТЗ.
Главное в ПО - это внутренняя красота, структура и код. Удобство использования придумали неудачники, которые не умеют программировать. Интерфейсы пользователя должны проектировать только программисты. Иначе как определить, что вписывается в красивую архитектуру системы, а какие фичи надо вычеркнуть. Ну действительно, не менять же из-за них эту замечательную диаграмму классов!Чем сложнее интерфейс пользователя, тем больше вашу команду будут уважать, как разработчиков "такой сложной системы".
Если программист сидит и не строчит по клавиатуре, значит он бездельничает и его надо наказать. Те, кто говорит, что, перед тем, как писать код, нужно подумать, – лодыри, которые не хотят работать. "Продумывание архитектуры" - это вечный повод ничего не делать и тратить бюджет проекта. Вы же не дом строите, чтобы задумываться об архитектуре.
Ни в коем случае не делайте прототипы. Вы потратите бюджет, а в результате получится непонятная и одноразовая поделка. Если вы, вдруг, уже написали прототип, ни в коем случае не выбрасывайте его. Ведь это почти готовое приложение. Представьте, сколько времени и ресурсов было на него потрачено! Если чуть-чуть доделать прототип, то вполне можно писать остальную систему на его основе.
Разработка
Никогда не забывайте, что вы разбираетесь в технологии лучше всех. Поэтому обязательно несколько раз в день вам надо ходить, читать код программистов и критиковать его. Достаточно сказать, что код, который написал программист – отстой. Ни в коем случае не говорите, почему, даже если знаете. Программист должен до всего доходить собственным умом – пусть подумает сам.
Лично просматривайте каждую строчку кода, написанного программистами. Пусть они знают, что вы им не доверяете, и любая ошибка, которую они допустят, будет вами найдена, а они – наказаны.
Ставить задачи программистом лучше всего устно. У вас и так нет времени, чтобы отвлекаться и детально описывать проблему, а у программистов память хорошая – запомнят. Кстати, чем больше задач на неделю программисту поставить, тем больше он сделает.
Обязательно обсуждайте с программистом возникшие вопросы сразу, как только вы про них вспомнили. Им ничего не стоит переключиться с текущей задачи на проект трёхлетней давности, а вы ведь можете и забыть, что хотели уточнить.
Не стоит давать сотруднику работать над одной задачей непрерывно более 15 минут. Переключите его на другую задачу, если видите, что он увлечённо работает. Высока вероятность, что он упорствует в ошибке, и потом придётся всё за ним переделывать. К тому же, переключение программиста между задачами способствует развитию внимания и краткосрочной памяти.
Контроль качества и ошибки
За каждую найденную ошибку надо давать тестировщику премию, вычитая её из зарплаты программиста. Впрочем, тестировщики на проекте вообще не нужны. Программисты могут тестировать свой код сами.Всячески поощряйте конфликты между тестировщиками и программистами. Тестировщики должны ненавидеть программистов. Тогда поиск ошибок становится для них ещё и личным делом, и они тестируют гораздо лучше.
Если в проекте найден баг, обязательно выясните, кто его допустил и прилюдно выскажите своё порицание провинившемуся программисту. Дайте понять не только ему, но и всей команде, что он непрофессионал. Настоящие профессионалы ошибок не совершают.
Нет смысла тестировать версию перед релизом. Это пустая трата проектного бюджета. Вы и так знаете, что профессиональные программисты ошибок не допускают.
Никогда не пишите юнит-тесты – это пустая трата ресурсов. Они значительно увеличивают сроки разработки, а в результате всё равно никто их не запускает.
Вредные советы руководителю проектов
2012-04-08 16:11:00 (читать в оригинале)Хотите выпускать продукт низкого качества, постоянно проваливая при этом сроки? Хотите разорванных контрактов и разъярённых заказчиков? Хотите, чтобы вас ненавидела ваша команда? Тогда этот пост для вас!
План и сроки
Назначайте все сроки сами. Программисты ленивы и, поэтому, всегда будут завышать оценку в пять раз, чтобы ничего не делать. Даже если программист оценил задачу – уменьшите оценку как минимум втрое. В состоянии вечного цейтнота программисты мобилизуются и работают гораздо лучше.
Программисты – ленивые недоучки, которые никогда не упустят возможность побездельничать. Каждые 15 минут проверяйте, что они делают, заглядывая им в монитор. Так вы заставите их постоянно работать и тем самым улучшите производительность. Ещё лучше, если у каждого будет установлен клавиатурный шпион, а с экрана каждые две минуты будет сниматься скриншот и отправляться вам по почте.
Мотивация сотрудников – занятие никчёмное и бессмысленное. Вы платите сотрудникам деньги, зачем придумывать что-то ещё?Самое простое решение любой проблемы - уволить программиста. Не тратьте ваше ценное время на выяснение причин и мотивов его «плохого поведения». Программисты - обычный взаимозаменяемый ресурс.
Пусть программисты знают, что в любой момент их могут уволить. Этот страх многократно увеличит их производительность.
Если на программиста кричать и публично называть идиотом, он станет работать гораздо лучше, чтобы в будущем не дать вам повода для выговора. Это один из самых эффективных приемов мотивации.
Побольше обещайте. Обещание ценно само по себе и сильно мотивирует, даже если его не выполнить. К тому же, программисты редко помнят данные им обещания, поэтому выполнять их - пустая трата денег или других ресурсов.
Запомните: за любую оплошность программистов надо штрафовать. Они работают у вас за зарплату, поэтому уменьшение ее заставит их работать лучше, чтобы не допустить такого в будущем. Кстати, поощрять можно тоже только премиями. Очевидно, что любого наёмного сотрудника интересуют только деньги.
Ни в коем случае не обучайте программистов. Квалифицированный программист всегда хочет большую зарплату и запросто может убежать к конкурентам.
Если вашему подчиненному что-то мешает, он должен сидеть и терпеть. Вы не нянька, чтобы за каждым бегать. Да и вообще, неудобства закаляют волю. Никогда не хвалите программиста. Они от этого расслабляются и работают хуже.
Команда
Никогда не забывайте, что в команде вы самый главный. Не допускайте, чтобы у членов команды появилось собственное мнение. Они должны писать код. Думать - ваша работа.
Учтите, что каждый программист только и мечтает о том, как занять ваше место, поэтому всячески подавляйте наиболее успешных из них. Если начальство заметит их успехи они, чего доброго, поставят кого-нибудь из них на ваше место.
Обо всех неудачах и провалах ваших подчиненных надо немедленно докладывать начальнику. Пусть он знает, что виноваты в провале не вы, а программисты.
Начальство и бизнес
Ваш непосредственный начальник входит в пантеон высших богов. Никогда не спорьте с ним и выполняйте любую его волю с радостью. Пусть даже придется принести в жертву пару ваших программистов. Помните, что программисты приходят и уходят, а начальник остается.
Вас не должно волновать, откуда у фирмы берутся деньги. Пусть об этом думает директор. Вероятнее всего, они сами появляются в тумбочке день зарплаты. Сроки, бюджеты и бизнес-планы нужны только для того, чтобы занять работой аналитиков.
Постарайтесь сообщать обо всех неудачах вашего непосредственного начальника на уровень выше. Рано или поздно там поймут, что он не слишком профессионален и, конечно, поставят на его место вас – человека, который хорошо знает все ошибки предшественника и, вероятно, сумеет их избежать.
Отношение с заказчиком
Заказчик – полный идиот. Он ничего не понимает в системе, которую вы сейчас разрабатываете, и не заинтересован в её успехе. Он делает все исключительно для того, чтобы усложнить вам разработку. Других целей у него не бывает.Разговор с заказчиком - бессмысленная потеря времени. Всё, что надо, он и так написал в ТЗ.
Результат вашей работы достаточно показать заказчику в момент сдачи проекта. Не стоит тратить время на то, чтобы показывать ему промежуточные версии. Заказчику абсолютно безразлично, что вы там для него делаете, вряд ли он с радостью будет тратить на вас драгоценное время.
Продолжение следует...
Вредные советы руководителю проектов
2012-04-08 16:11:00 (читать в оригинале)Хотите выпускать продукт низкого качества, постоянно проваливая при этом сроки? Хотите разорванных контрактов и разъярённых заказчиков? Хотите, чтобы вас ненавидела ваша команда? Тогда этот пост для вас!
План и сроки
Назначайте все сроки сами. Программисты ленивы и, поэтому, всегда будут завышать оценку в пять раз, чтобы ничего не делать. Даже если программист оценил задачу – уменьшите оценку как минимум втрое. В состоянии вечного цейтнота программисты мобилизуются и работают гораздо лучше.
Программисты – ленивые недоучки, которые никогда не упустят возможность побездельничать. Каждые 15 минут проверяйте, что они делают, заглядывая им в монитор. Так вы заставите их постоянно работать и тем самым улучшите производительность. Ещё лучше, если у каждого будет установлен клавиатурный шпион, а с экрана каждые две минуты будет сниматься скриншот и отправляться вам по почте.
Мотивация сотрудников – занятие никчёмное и бессмысленное. Вы платите сотрудникам деньги, зачем придумывать что-то ещё?Самое простое решение любой проблемы - уволить программиста. Не тратьте ваше ценное время на выяснение причин и мотивов его «плохого поведения». Программисты - обычный взаимозаменяемый ресурс.
Пусть программисты знают, что в любой момент их могут уволить. Этот страх многократно увеличит их производительность.
Если на программиста кричать и публично называть идиотом, он станет работать гораздо лучше, чтобы в будущем не дать вам повода для выговора. Это один из самых эффективных приемов мотивации.
Побольше обещайте. Обещание ценно само по себе и сильно мотивирует, даже если его не выполнить. К тому же, программисты редко помнят данные им обещания, поэтому выполнять их - пустая трата денег или других ресурсов.
Запомните: за любую оплошность программистов надо штрафовать. Они работают у вас за зарплату, поэтому уменьшение ее заставит их работать лучше, чтобы не допустить такого в будущем. Кстати, поощрять можно тоже только премиями. Очевидно, что любого наёмного сотрудника интересуют только деньги.
Ни в коем случае не обучайте программистов. Квалифицированный программист всегда хочет большую зарплату и запросто может убежать к конкурентам.
Если вашему подчиненному что-то мешает, он должен сидеть и терпеть. Вы не нянька, чтобы за каждым бегать. Да и вообще, неудобства закаляют волю.Никогда не хвалите программиста. Они от этого расслабляются и работают хуже.
Команда
Никогда не забывайте, что в команде вы самый главный. Не допускайте, чтобы у членов команды появилось собственное мнение. Они должны писать код. Думать - ваша работа.
Учтите, что каждый программист только и мечтает о том, как занять ваше место, поэтому всячески подавляйте наиболее успешных из них. Если начальство заметит их успехи они, чего доброго, поставят кого-нибудь из них на ваше место.
Обо всех неудачах и провалах ваших подчиненных надо немедленно докладывать начальнику. Пусть он знает, что виноваты в провале не вы, а программисты.
Начальство и бизнес
Ваш непосредственный начальник входит в пантеон высших богов. Никогда не спорьте с ним и выполняйте любую его волю с радостью. Пусть даже придется принести в жертву пару ваших программистов. Помните, что программисты приходят и уходят, а начальник остается.
Вас не должно волновать, откуда у фирмы берутся деньги. Пусть об этом думает директор. Вероятнее всего, они сами появляются в тумбочке день зарплаты. Сроки, бюджеты и бизнес-планы нужны только для того, чтобы занять работой аналитиков.
Постарайтесь сообщать обо всех неудачах вашего непосредственного начальника на уровень выше. Рано или поздно там поймут, что он не слишком профессионален и, конечно, поставят на его место вас – человека, который хорошо знает все ошибки предшественника и, вероятно, сумеет их избежать.
Отношение с заказчиком
Заказчик – полный идиот. Он ничего не понимает в системе, которую вы сейчас разрабатываете, и не заинтересован в её успехе. Он делает все исключительно для того, чтобы усложнить вам разработку. Других целей у него не бывает.Разговор с заказчиком - бессмысленная потеря времени. Всё, что надо, он и так написал в ТЗ.
Результат вашей работы достаточно показать заказчику в момент сдачи проекта. Не стоит тратить время на то, чтобы показывать ему промежуточные версии. Заказчику абсолютно безразлично, что вы там для него делаете, вряд ли он с радостью будет тратить на вас драгоценное время.
Продолжение следует...
Про вред молчания
2012-04-04 15:25:00 (читать в оригинале)Товарищи, хочу поднять тему, которая уже очень долгое время меня волнует. Может быть, кому-то она покажется слишком резкой, а кому-то слишком нескромной, но тем не менее.
Лично мне как руководителю много неудобств приносят люди, которые чем-то недовольны, но молча сидят и ждут. Молча ждут, пока им поднимут зарплату. Молча занимаются неинтересной работой в надежде, что когда-нибудь я это замечу и осчастливлю новым проектом. Молча мёрзнут под кондиционером и уходят на больничный, так и не попросив его выключить.
Люди сидят, молчат и, молча, обижаются. А потом, когда предел ожидания достигнут, они вместо того, чтобы придти ко мне и рассказать о проблеме, также молча идут в соседнюю фирму на собеседование.
Дальше текст немного в «чёрном» стиле. Я надеюсь, вас не смутит обращение на «ты», поскольку оно лучше передаёт эмоциональную составляющую и смысл статьи.
Монолог руководителя
Ты сидишь, молчишь и обижаешься на что-то.
Мне всегда хочется сказать: «ну что за детский сад!». Я что — телепат? Да ты просто не имеешь права обижаться, пока ты не сказал мне, что у тебя за проблема! Зачем молчать в углу.
Если у тебя есть проблема – я всегда готов её решить. Будь уверен, если она не решается, или я, по какой-то причине, не готов её решать сейчас – я сам тебе скажу об этом. Но, так или иначе, буду думать, как тебе помочь.
Если у тебя есть потребность – выражай её. Иначе о ней никто так и не узнает.
У тебя медленный компьютер, и ты компилируешь код два часа в день? Почему ты молчишь и остаёшься сверхурочно, попутно накапливая от этого обиду? Да твои два часа в день стоят дороже отдельного билд-сервера! Скажи — и я буду решать твою проблему и либо найду тебе новый компьютер, либо попрошу потерпеть до момента, когда придёт финансирование. Но я буду в курсе. И буду работать над этим.
Ты у нас уже три года и за это время вырос до серьёзного программиста, а зарплату тебе так и не подняли? Да, согласен, я недосмотрел. Вообще-то такие вещи руководитель должен контролировать сам. Но зачем вставать и уходить в другую фирму только потому, что у них зарплата на 10% больше? Просто скажи мне об этом. Думаешь мне хочется, чтобы у меня один из лучших программистов непрерывно находился в состоянии стресса, а потом сваливал во фриланс? Я почти уверен, что мы договоримся, и ты получишь повышение. И будешь счастлив. И, представляешь, я тоже буду счастлив. Потому что (вот удивительно!) мне нравится, когда мои программисты счастливы. Да и работать ты, счастливый, будешь лучше – доказанный факт.
Ты вчера написал письмо с предложением улучшения производительности компонента, а я так и не ответил? Давай честно: вчера мне написало двадцать человек, не считая спамеров. Да я, может быть, просто забыл про твоё замечательное предложение. Подойди и спроси. Если я пока не считаю его актуальным – я прямо тебе это скажу. А может быть, я, наконец, выкопаю его со дна почтового ящика, прочитаю и скажу: «Круто, парень! Вот тебе премия».
Ты считаешь, что всю жизнь будешь писать бухгалтерские формочки, а тебе хочется писать высоконагруженные системы? Ты думаешь, что мы никогда этим не занимались, не занимаемся и заниматься не будем? И даже спрашивать не стоит? Да представь себе, я уже с ног сбился в поисках человека, которому бы мог поручить эту задачу.
Даже если нам не нужны высоконагруженные системы, я тебе скажу об этом прямо. Ты будешь знать наверняка, что, вероятно, надо менять работу. И я, в общем-то, к этому буду готов. А может быть я задумаюсь: «а не попробовать ли?». Почему нет?
Ты уже три месяца исправляешь ошибки в чужом коде? Тебя это достало, но ты молчишь и уже рассылаешь резюме? Да ты хоть раз попробовал мне об этом сказать? А то я смотрю на тебя и удивляюсь: «как это тебе нравится копаться с этими неуловимыми глюками – другой бы давно уже возмутился, а ты всё работаешь. Значит – нравится».
Таких примеров миллион. Более чем уверен, что в жизни любого, кто сейчас читает эту статью, их хватает.
Резюме
Если хотите, чтобы ваша проблема решилась – скажите об этом. Просто сидеть и молча ждать – самое неконструктивное решение.
Просто скажите. Да, это сложно. Это очень сложно, т.к. заставляет переступить через свою пассивность и опасения, что вас не так поймут. Уверяю вас, если вы будете молчать, поймут вас ещё менее правильно. Если поймут вообще.
И не надо забывать старую мудрость: коммуникация – ключ к взаимопониманию!
Категория «Художники»
Взлеты Топ 5
 | ||
|
+288 |
299 |
verun_shatun |
|
+277 |
284 |
иллюстрированный ежедневник |
|
+264 |
289 |
milhauz |
|
+6 |
29 |
BobRosStyle |
|
|
|
|
Падения Топ 5
 | ||
|
-5 |
206 |
Мастерская кукол и хорошего настроения |
|
-15 |
3 |
Журнал пользователя gapchinska74@mail.ru |
|
-251 |
5 |
vz8 |
|
-272 |
6 |
zaraboika |
|
|
|
|
Популярные за сутки
Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.
взяты из открытых общедоступных источников и являются собственностью их авторов.