И я тоже набил, поверьте. И тоже считал, что нет ничего хуже заказчика, который плохо представляет себе желаемый результат. А теперь вот понял, что другая крайность — не меньшая проблема.
Во-первых, старинный интерфейс не будет особой проблемой, раз уж система для собственного пользования делается.
Во-вторых, при заказной разработке серьезной корпоративной системы, как показывает практика, всегда будет вендор-лок, даже если заказчик получит исходники с правами.
Лично в моем опыте Подрядчика самым лучшим был проект, где ТЗ занимало 5 томов по 700 страниц с делением по дисциплинам, с прописыванием всего и вся. И таки это был немецкий Заказчик.
Как интересно! А можно поподробнее? Что там имело основной вес? Описание предметной области? Бесконечные UML-диаграммы? Мокапы?
Блин, это же получается надо в календарном плане отделно прописывать — Этап 1. Изучение ТЗ. 1 месяц. $10 000. :)
А при чем тут дизайнер? Дизайнер будет решать как будут работать коментарии? Нет. Зачастую они рисуют красивую картинку, вовсе не задумываясь глубоко над возможными вариантами.
В моём случае всё, что отображается на мониторе — сфера компетенции UX-дизайнера. Менеджер должен описать функцию премодерации, а уже дизайнер решает — куда будет приходить уведомление о новом комменте, где будут кнопки для его просмотра, какие будут варианты у админа по взаимодействию с автором, будут ли при этом показыаться его последние 10 сообщений и пр…
Как подрядчику по разработке ПО у меня лучше всего получалось работать с теми заказчиками, кто формулировал требования на уровне бизнес-целей и общих задач типа: Система должна обеспечивать возможность просмотра документа.
Тогда работать лучше всего, поскольку на нас и проектирование и разработка, то пропасти между ними нет. Проектируем с учетом своих возможностей и способностей. Максимум пространства для маневра. И заказчик доволен — у него всё работает.
Но это возможно только когда заказчик является конечным пользователем.
В моём же случае я был вендором, отдавшим разработку на аутсорсинг. Для меня — это коммерческий проект. Результат работы я намереваюсь продавать. Соответственно, если мой подрядчик, к примеру, реализует все функции но интерфейс будет на уровне 90-х годов — мой сервис никто не купит. Поэтому мои ожидания более конкретны и ТЗ более детализировано.
В первом случае чем больше у разработчика пространства для манёвра — тем ниже риски у заказчика.
Во втором случае один неправильный манёвр разработчика может погубить весь бизнес.
Я тоже пришел к выводу о том, что необходимо давать разработчику пространство для маневра. В противном случае сложность разработки для разработчика возрастет и кпд разработки будет ниже.
Ну это палка о двух концах. Сколько было случаев, когда после таких манёвров случались диалоги типа:
— А я думал, пуговицы будут перламутровыми
— В ТЗ цвет не прописан, мы сделали на своё усмотрение
— Но это же очевидно, что они должны быть перламутровые!!!
— Перламутровые вообще не будут застёгиваться!
— Нет, делайте перламутровые, я ваш заказчик
…
— Ой, а чё не застёгиваются?
Банальная ситуация — все свои разработчики заняты в долгосрочных проектах. Отдать на аутсорс казалось дешевле, потому что не было затрат на поиск дополнительного персонала, его обучение и пр…
Хмм. А подойти и сказать — «вот так реализовать проблематично, придётся сплясать с бубном, но можно сделать так, разница для пользователя не велика, а разница во времени разработки — в 3 раза?» Мало ли, вдруг и договоритесь. Попробовать то можно ж
Мы пытались так делать. К слову у меня ушла пара месяцев просто на то, чтобы приучить разработчиков хотя бы оценивать сложность реализации экронов перед их вёрсткой и высказывать своё мнение. Но даже после этого всё равно случались заковырки, когда какой-нибудь pop-up упорно не хотел нормально появляться-скрываться.
Конечно, после двух недель мучений разработчик предлагал, к примеру всю форму перенести в лайтбокс, но в середине проекта менять концепцию интерфейса нельзя — поэтому приходилось биться головой об стену и учиться-учиться-учиться. А это куча дополнительного времени и денег.
Во-первых, старинный интерфейс не будет особой проблемой, раз уж система для собственного пользования делается.
Во-вторых, при заказной разработке серьезной корпоративной системы, как показывает практика, всегда будет вендор-лок, даже если заказчик получит исходники с правами.
Как интересно! А можно поподробнее? Что там имело основной вес? Описание предметной области? Бесконечные UML-диаграммы? Мокапы?
Блин, это же получается надо в календарном плане отделно прописывать — Этап 1. Изучение ТЗ. 1 месяц. $10 000. :)
В моём случае всё, что отображается на мониторе — сфера компетенции UX-дизайнера. Менеджер должен описать функцию премодерации, а уже дизайнер решает — куда будет приходить уведомление о новом комменте, где будут кнопки для его просмотра, какие будут варианты у админа по взаимодействию с автором, будут ли при этом показыаться его последние 10 сообщений и пр…
Как подрядчику по разработке ПО у меня лучше всего получалось работать с теми заказчиками, кто формулировал требования на уровне бизнес-целей и общих задач типа:
Система должна обеспечивать возможность просмотра документа.Тогда работать лучше всего, поскольку на нас и проектирование и разработка, то пропасти между ними нет. Проектируем с учетом своих возможностей и способностей. Максимум пространства для маневра. И заказчик доволен — у него всё работает.
Но это возможно только когда заказчик является конечным пользователем.
В моём же случае я был вендором, отдавшим разработку на аутсорсинг. Для меня — это коммерческий проект. Результат работы я намереваюсь продавать. Соответственно, если мой подрядчик, к примеру, реализует все функции но интерфейс будет на уровне 90-х годов — мой сервис никто не купит. Поэтому мои ожидания более конкретны и ТЗ более детализировано.
В первом случае чем больше у разработчика пространства для манёвра — тем ниже риски у заказчика.
Во втором случае один неправильный манёвр разработчика может погубить весь бизнес.
Ну да… наверное подбор правильных подрядчиков это отдельная профессия… :)
Ну это палка о двух концах. Сколько было случаев, когда после таких манёвров случались диалоги типа:
— А я думал, пуговицы будут перламутровыми
— В ТЗ цвет не прописан, мы сделали на своё усмотрение
— Но это же очевидно, что они должны быть перламутровые!!!
— Перламутровые вообще не будут застёгиваться!
— Нет, делайте перламутровые, я ваш заказчик
…
— Ой, а чё не застёгиваются?
Мы пытались так делать. К слову у меня ушла пара месяцев просто на то, чтобы приучить разработчиков хотя бы оценивать сложность реализации экронов перед их вёрсткой и высказывать своё мнение. Но даже после этого всё равно случались заковырки, когда какой-нибудь pop-up упорно не хотел нормально появляться-скрываться.
Конечно, после двух недель мучений разработчик предлагал, к примеру всю форму перенести в лайтбокс, но в середине проекта менять концепцию интерфейса нельзя — поэтому приходилось биться головой об стену и учиться-учиться-учиться. А это куча дополнительного времени и денег.