Вредные советы руководителю проектов. Часть 2

В первой части "вредных советов" я объяснил, как надо правильно работать  с планами,  командой и заказчиком, чтобы успешно провалить проект. В этой части речь пойдёт о процессе разработки и тестирования.

Проектирование

Достаточно дать программисту "смутные мысли заказчика" на одном листке, чтобы через неделю ожидать готовой функциональности. Он же профессионал!

Программисты всегда лучше, чем заказчик знают, как должно работать приложение. Они же его пишут. Кстати, требования тоже придуманы только для того, чтобы мешать программистам творить. Поэтому программисты должны смело писать так, как считают правильным, не оглядываясь на всякую бюрократию, вроде ТЗ.

Главное в ПО - это внутренняя красота, структура и код. Удобство использования придумали неудачники, которые не умеют программировать. Интерфейсы пользователя должны проектировать только программисты. Иначе как определить, что вписывается в красивую архитектуру системы, а какие фичи надо вычеркнуть. Ну действительно, не менять же из-за них эту замечательную диаграмму классов!

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

Если программист сидит и не строчит по клавиатуре, значит он бездельничает и его надо наказать. Те, кто говорит, что, перед тем, как писать код, нужно подумать, – лодыри, которые не хотят работать. "Продумывание архитектуры" - это вечный повод ничего не делать и тратить бюджет проекта. Вы же не дом строите, чтобы задумываться об архитектуре.

Ни в коем случае не делайте прототипы. Вы потратите бюджет, а в результате получится непонятная и одноразовая поделка. Если вы, вдруг, уже написали прототип, ни в коем случае не выбрасывайте его. Ведь это почти готовое приложение. Представьте, сколько времени и ресурсов было на него потрачено! Если чуть-чуть доделать прототип, то вполне можно писать остальную систему на его основе.

Разработка

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

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

Лично просматривайте каждую строчку кода, написанного программистами. Пусть они знают, что вы им не доверяете, и любая ошибка, которую они допустят, будет вами найдена, а они – наказаны.

Ставить задачи программистом лучше всего устно.  У вас и так нет времени, чтобы отвлекаться и детально описывать проблему, а у программистов память хорошая – запомнят. Кстати, чем больше задач на неделю программисту поставить, тем больше он сделает.

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

Не стоит давать сотруднику работать над одной задачей непрерывно более 15 минут. Переключите его на другую задачу, если видите, что он увлечённо работает. Высока вероятность, что он упорствует в ошибке, и потом придётся всё за ним переделывать. К тому же,  переключение программиста между задачами способствует развитию внимания и краткосрочной памяти.

Контроль качества и ошибки

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

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

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

Нет смысла тестировать версию перед релизом. Это пустая трата проектного бюджета. Вы и так знаете, что профессиональные программисты ошибок не допускают.

Никогда не пишите юнит-тесты – это пустая трата ресурсов. Они значительно увеличивают сроки разработки, а в результате всё равно никто их не запускает.