Комментарии 11
взаимодействие триумвирата: менеджера, разработчика и заказчика.
Э-э-э… Это вряд ли триумвират. Как по-научному называется композиция «лебедь, рак и щука»?
Помнится, после ВУЗа я сделал открытие — если сваять на C++ Builder за пару часов для заказчика макет приложения, вообще без функционала, только кнопки, то контракт обычно подписывается именно с нами и проблем с UI на сдаче не возникает. Шеф, технарь до мозга костей, разумеется, считал меня дураком, но держал — за умение общаться с такими же, как я, дураками у заказчика.
Это уже сильно после я прочел про «Соломенное чучело» у деМарко
Это уже сильно после я прочел про «Соломенное чучело» у деМарко
Проблема таких вот макетов — в том, что заказчик считает их почти готовыми приложениями и в своих оценках сроков исходит из этого предположения...
Ну если ему через пару часов (а не недель) принести макет, он не станет считать его готовым приложением.
И еще один плюс в таком поведении заказчика — он может принять первый этап практически с парой реализованных функций из сотни, лишь бы они на кнопках висели. Тогда он не будет бояться, что вы некомпетентны, точнее, будет бояться сильно меньше.
И еще. Получив в руки работающую программу, заказчик очень быстро расставит приоритеты, что ему в самом деле надо, а что — не очень. Поэтому и приемка этапов проходит гладко, за все важные функции он вас уже поимел в процессе и получил, что хотел, и с легкостью переносит сроки на допиливание третьестепенного функционала, а иногда вообще просто махает рукой — нет, да и не очень надо, как выяснилось.
Заказчику, особенно государственному, надо дать в руки хоть как-то работающую программу, но как можно быстрее. Собственно, суть всех гибких методологий именно в этом
И еще один плюс в таком поведении заказчика — он может принять первый этап практически с парой реализованных функций из сотни, лишь бы они на кнопках висели. Тогда он не будет бояться, что вы некомпетентны, точнее, будет бояться сильно меньше.
И еще. Получив в руки работающую программу, заказчик очень быстро расставит приоритеты, что ему в самом деле надо, а что — не очень. Поэтому и приемка этапов проходит гладко, за все важные функции он вас уже поимел в процессе и получил, что хотел, и с легкостью переносит сроки на допиливание третьестепенного функционала, а иногда вообще просто махает рукой — нет, да и не очень надо, как выяснилось.
Заказчику, особенно государственному, надо дать в руки хоть как-то работающую программу, но как можно быстрее. Собственно, суть всех гибких методологий именно в этом
Допустим, сердце системы — БД, и нужно реализовать работу с Oracle.
Вы предлагаете сляпать по-быстрому пару функций на SQLite, прямыми запросами, без ORM, а потом, получив мелкое требование: «а сюда добавьте ещё пару критериев в выборку», получить переделку на 2 месяца якобы уже готовых фич, потому что правильно было их писать ну совсем с другой схемой данных, а не с игрушечной?
Вы предлагаете сляпать по-быстрому пару функций на SQLite, прямыми запросами, без ORM, а потом, получив мелкое требование: «а сюда добавьте ещё пару критериев в выборку», получить переделку на 2 месяца якобы уже готовых фич, потому что правильно было их писать ну совсем с другой схемой данных, а не с игрушечной?
«А почему у вас кнопка удаления не там, где кнопка редактирования?».
После этой фразы должно быть что-то вроде такого:
— Сделано согласно утвержденного ТЗ, вот тут написано и нарисовано. Хотите перенести? Давайте составим новое ТЗ с доплатой за переделку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Две картины с заказчиком