Экскурс в историю
С какого-то места разработчик начинает доверять более себе и менее неким абстрактным истинам, вне зависимости из-под клавиатуры какого гуру они появились на свет. Эргономика интерфейса для большого числа разработчиков подразумевает вполне ясные и конкретные решения в контексте обратной реакции пользователей.
Встречаясь с разработчиками на прошлой неделе (Волгоград, Ростов-на-Дону, Краснодар) я имел смелость рассказать небольшую байку из своей прошлой жизни, когда моей задачей было не только "открыть" проект, но и "закрыть" его, т.е. сдать заказчику. Все эти "здравые" рассуждения о вреде водопадной модели и пользе agile-методологии очень хорошо подходят для юнцов, не нюхавших пороха баталий с заказчиками, представляющих собой отнюдь не бизнесменов, рискующих 2-3 тысячами долларов за-ради создания очередного сайта компании. Нормальный заказчик держится за водопадную модель как бухгалтер за калькулятор, поэтому предложение работать с "гибким" ТЗ минимум поднимает брови и ответственных людей, а максимум - вы можете легко прослыть "городским сумасшедшим". Собственно, на эту тему я делал доклад на конференции Agile Days, что чуть не закончилось дракой.
Но драчливость программистов забавна настолько, насколько торчит животик корпоративного вещуна в не менее корпоративной майке. Премилой будет и моя настоящая история.
Особенности работы с серьезными заказчиками
Проект я делал для серьезного заказчика. Серьезность заказчика определяется даже не стоимостью проекта, а тяжестью последствий прежде всего для него. На верхнем уровне абстракции думаешь не об "эргономике" проекта в целом, т.е. в насколько неудобное положение ты поставишь заказчика своим ПО. Своих я бы подставил по-полной.
В классике управления проектами по созданию ПО принято выделять следующие риски:
- технологический риск - типа среда разработки или библиотека компонентов своим качеством не обеспечит темп разработки;
- риск компетенции разработчиков - программисты "не потянут" проект вследствие его сложности;
- риск, связанный и изменением требований заказчика;
- политические риски.
Технологический риск мы прикроем просто - возьмём Delphi - надёжный, испытанный инструмент. Да и C++Builder здесь вполне качественная среда и также стабильно приносила мне деньги. А вот библиотеки сторонних разработчиков дело тонкое. Тут главное не гоняться за дешевизной во всех смыслах этого слова.
Компетенция разработчиков вопрос несложный. Грубо говоря - выбирай по себе дерево. Ну и живи активной жизнью - ходи на форумы, общайся. В любой момент тебе помогут кодом или посоветуют, куда копать.
Политические риски - типа твой проект хотят умышленно "убить" - было такое, но тут могу посоветовать одно - паши, как конь, и дух святого покровителя программистов тебя убережёт.
Риск изменения требований заказчика повышается умышленно, если вы работаете по agile. Хотите этого? Вперёд. У меня заказчик был такой, что проект принимала комиссия. Супер? Да? На этапе разработки вы полностью удовлетворяете требованиям заказчика, а программу принимает его "старший коллега", которому объяснять ничего не надо. Он смотрит в ТЗ, смотрит в программу и делает выводы. И манифестом тут ничего не объяснить и не прикрыться.
Тут мы все понимаем, что agile здесь даже не то, что не коллинеарен, не перпендикулярен, а противонаправлен. А вот что может вас уберечь от изменения требований заказчика (говоря простым языком - "раскатывания губ")? При всём уважении к апологетам agile так и подмывает спросить, а как часто изменение требований заказчика связано с уменьшением объёмов работы? Бугагашенька.
Хорошее ТЗ - вот что нам нужно. Но тут особо не застрахуешься, чистый функционал есть вполне чёткая тема, и жонглирование терминами тут даёт степень свободы, но отнюдь не всемогущество. А вот полезняшки вроде повышенной эргономики помогают расположить к себе заказчика. Как я неустанно повторяю - "красивый интерфейс сродни красивой женщине, которой за красоту можно многое простить, включая определённые баги". (моя, например, заставила меня вчера делать котлеты из щуки).
Где история?
Автор, ты - котлет переел настолько, что он с каждым новым абзацем всё дальше уходит от обещанной сказочки? Извольте.
- Котлет я еще не ел, только сделал.
- В фарш из филе нужно добавить свининки для нажористости.
- Мух добавлять не надо. Если муху можно назвать багом, то броское выражение (catchprase) вполне соответствует духу IT.
Делал я программу в Windows XP. Общение с заказчиком проходило на моём компьютере, поэтому интерфейс, ставший уже привычным для пользователя, были именно XP-шным. А финальная сдача программы была на ноутбуке с Windows 7 (мы поставляли программно-аппаратный комплекс, т.е. нотик+софт).
На сдаче "мой человек" увидел программу, но с интерфейсом Windows 7. И сказал публично - "Сева, сразу видно, что перед сдачей ты серьёзно поработал с интерфейсом - он стал более красивым". Вот так найденный на дороге клад сильно поддомкратил мой имидж профессионального разработчика.
При чём тут FireMonkey?
Это просто новый фреймворк/библиотека, которая позволяет делать очень качественные, модные и красивые интерфейсы. И пренебрегать этим не стоит. В конечном итоге, интерфейс ( междумордье ) - есть образ вас как разработчика перед заказчиком. Даже если вы - внутрикорпоративный разработчик. Причём именно тут я бы даже больше беспокоился. Одно дело - сдал проект - забыл. Другое дело - каждый день видится с "благодарными пользователями". И уж точно, что более броские и яркие интерфейсы делают вас самих более дорогим (во всех смыслах) в глазах сотрудников. И даже тех, кто начисляет вам зарплату и принимает решение о её повышении.
Подумайте об этом 