![]() ![]() ![]()
Какой рейтинг вас больше интересует?
|
![]()
Вредные советы руководителю проектов. Часть 22012-04-12 18:48:00 (читать в оригинале)В первой части "вредных советов" я объяснил, как надо правильно работать с планами, командой и заказчиком, чтобы успешно провалить проект. В этой части речь пойдёт о процессе разработки и тестирования. Проектирование![]() Программисты всегда лучше, чем заказчик знают, как должно работать приложение. Они же его пишут. Кстати, требования тоже придуманы только для того, чтобы мешать программистам творить. Поэтому программисты должны смело писать так, как считают правильным, не оглядываясь на всякую бюрократию, вроде ТЗ. ![]() Чем сложнее интерфейс пользователя, тем больше вашу команду будут уважать, как разработчиков "такой сложной системы". Если программист сидит и не строчит по клавиатуре, значит он бездельничает и его надо наказать. Те, кто говорит, что, перед тем, как писать код, нужно подумать, – лодыри, которые не хотят работать. "Продумывание архитектуры" - это вечный повод ничего не делать и тратить бюджет проекта. Вы же не дом строите, чтобы задумываться об архитектуре. Ни в коем случае не делайте прототипы. Вы потратите бюджет, а в результате получится непонятная и одноразовая поделка. Если вы, вдруг, уже написали прототип, ни в коем случае не выбрасывайте его. Ведь это почти готовое приложение. Представьте, сколько времени и ресурсов было на него потрачено! Если чуть-чуть доделать прототип, то вполне можно писать остальную систему на его основе. Разработка![]() Достаточно сказать, что код, который написал программист – отстой. Ни в коем случае не говорите, почему, даже если знаете. Программист должен до всего доходить собственным умом – пусть подумает сам. Лично просматривайте каждую строчку кода, написанного программистами. Пусть они знают, что вы им не доверяете, и любая ошибка, которую они допустят, будет вами найдена, а они – наказаны. Ставить задачи программистом лучше всего устно. У вас и так нет времени, чтобы отвлекаться и детально описывать проблему, а у программистов память хорошая – запомнят. Кстати, чем больше задач на неделю программисту поставить, тем больше он сделает. Обязательно обсуждайте с программистом возникшие вопросы сразу, как только вы про них вспомнили. Им ничего не стоит переключиться с текущей задачи на проект трёхлетней давности, а вы ведь можете и забыть, что хотели уточнить. Не стоит давать сотруднику работать над одной задачей непрерывно более 15 минут. Переключите его на другую задачу, если видите, что он увлечённо работает. Высока вероятность, что он упорствует в ошибке, и потом придётся всё за ним переделывать. К тому же, переключение программиста между задачами способствует развитию внимания и краткосрочной памяти. Контроль качества и ошибки![]() Всячески поощряйте конфликты между тестировщиками и программистами. Тестировщики должны ненавидеть программистов. Тогда поиск ошибок становится для них ещё и личным делом, и они тестируют гораздо лучше. Если в проекте найден баг, обязательно выясните, кто его допустил и прилюдно выскажите своё порицание провинившемуся программисту. Дайте понять не только ему, но и всей команде, что он непрофессионал. Настоящие профессионалы ошибок не совершают. Нет смысла тестировать версию перед релизом. Это пустая трата проектного бюджета. Вы и так знаете, что профессиональные программисты ошибок не допускают. Никогда не пишите юнит-тесты – это пустая трата ресурсов. Они значительно увеличивают сроки разработки, а в результате всё равно никто их не запускает.
|
![]() ![]() ![]()
Категория «Природа»
Взлеты Топ 5
Падения Топ 5
![]()
Популярные за сутки
|
Загрузка...

BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.
взяты из открытых общедоступных источников и являются собственностью их авторов.