Григорий Добряков – Блог про IT+AI

Функциональное проектирование сверху вниз не подходит для программных систем с долгим жизненным циклом, включающим их изменения и повторное использование.

Бертран Мейер

Эта ёмкая фраза была высказана на очередной Интернет-конференции в Санкт-Петербурге, в отеле “Ольгино”. Организатором выступили Роцит, Битрикс, Тринет (Алексей Довжиков, ты хорошо смотрелся к золотым кубком!). Правда, первый же минус в организации мероприятия – километровая очередь на входе – сыграл мне на руку: очередь, сама того не зная, стояла на регистрацию по фамилиям на буквы М-Я, а я быстренько получил бейдж и мешок цветной макулатуры у стенда с буквами А-Л.

Само мероприятие получилось просто удивительным. На церемонию открытия набралось столько народу, что некоторым пришлось стоять вдоль стен – в самом большом зале просто не было мест. Организаторы держали речь, Довжиков получил кубок “Интернет-марафона”, фотографы щелкали вспышками, а серьезный дядька в углу снимал всех на телекамеру.

Потом мы разделились и каждый пошел на свою секцию – весь день читались более четырех докладов одновременно. Я пошел, как ни странно, на доклад “где же деньги в интернете”. Апофеозом доклада стала фраза одного из тринетовцев: “где же деньги? а деньги у нас!” 🙂

Дальше было скучно. Женщина средних лет, представитель фирмы GoodsMatrix (логотип которой как две капли воды похож на логотип студии Лебедева, только раскрашенный явно под действием LSD) читала речь по бумажке и показывала слайды презентации. Речь была неинтересной, а в слайдах я успевал находить по три-четыре орфографических ошибки. Через полчаса я не выдержал и ушел греться и спать в машине на солнышке.

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

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

Это было не самое информативное, но самое впечатляющее выступление. Хмурый парень с полчаса рассказывал о преимуществах визуальной подачи информации. Рассказывал достаточно талантливо – очень много высказанных им мыслей я записал для дальнейшего обдумывания. Но весь народ в зале уже слегка притомился в ожидании. “Ха!” – сказал докладчик. – “Что это я вам рассказываю. Давайте лучше покажу”. И показал! И посыпались вопросы: “а сколько это весит?”, “а какой канал нужен?”, “а как это делается?”, “а существуют ли плагины?” и так далее… Обычный такой CounterStrike (или Quake, кому что ближе). В магазине. С возможностью ходить, двигать предметы, рассматривать их с неслабым приближением, закрывать и открывать окна (оценивая широкую панораму), расставлять мебель, включать видеотехнику (и смотреть фильмы), открывать двери, шкафы, холодильники… Брать с полки, допустим, обувь, и крутить ее перед глазами с размером на весь экран и с весьма чётким разрешением. При всём этом, технология VolumePhoto (обзор из одной точки на 360 градусов) была отмечена как вчерашний день… С удовольствием прорекламирую фирму: http://www.enternetica.com/rus/

Дальше было несколько небольших докладов про сенсорные киоски и про интернет-радио. Вдохновленные услышанным, мы побежали тыкать пальцами в экран ближайшего сенсорного киоска и пытаться научиться ими пользоваться. Кстати, реальный вывод из практики: области активной навигации реально должны быть большими. Палец – не курсор мыши: область для клика нужно делать большой.

Под вечер был доклад UsabilityLab. Начался весьма символично: “просим поднять руки тех, кто уверен, что их продукты удобны для пользователей”. Реакцию нетрудно представить… Доклад действительно был интересным – все строки со слайдов презентации хотелось переписать. Но… Ребята из usabilitylab, простите нас, мы были вынуждены уйти раньше всех: удивительным образом сложилось так, что тринет приурочил эту конференцию к моему дню рождения. Пришлось уйти раньше, и, объезжая пробки, под самый вечер примчаться в офис с бутылками шампанского.

Ждем итогов на sp-ik.ru 🙂

Абсолютно не нужно разбираться во всём. Нужно уметь делать ровно две вещи:
1. Чтобы проект был выполнен в достаточно краткие сроки, и по достаточно низкой себестоимости.
2. Чтобы при этом все участники процесса, начиная от заказчика и заканчивая самым неопытным стажером в группе разработчиков, были довольны.

Как ни странно, уже почти 10 лет работая на российском рынке, я много раз общался с руководителями известных российских компаний, но ни разу лично не встречал Артемия Лебедева. Сегодня это наконец-то произошло 🙂 Заверяю: Лебедев – не миф и не вымышленный персонаж. Это приятный в общении, интересный человек, который умеет расположить к себе аудиторию, сохраняет здравость мысли, остроумие и способность к активному творчеству. Остались исключительно хорошие впечатления от встречи.
http://www.artlebedev.ru/studio/

Помимо умения понимать оперативную обстановку военачальникам нужно доводить свои решения до многочисленных подчиненных и добиваться их исполнения. Это означает определенную жесткость, даже жестокость, умение психологически давить на собеседника и даже ораторские способности. В этом полководцы сродни крупным предпринимателям, политикам или воротилам промышленности. Только в отличие от владельцев сталелитейных заводов в подчинении у военачальников находятся люди, которые каждый день рискуют жизнью. «Бить их рублем» бесполезно, их можно или убеждать, или подавлять психологически. К этим способностям примыкает дар принятия решения. В отличие от кабинетного ученого военачальник принимает решения в условиях недостатка информации, не имея просто физической возможности всесторонне обдумать приказы и распоряжения. У него нет времени на рефлексию: он опирается только на свой опыт и интуицию. Причем после выбора того или иного варианта действий чаще всего нужно упрямо гнуть свою линию, т.к. последовательное проведение в жизнь пусть не лучшего решения на войне гораздо лучше приводящих к хаосу метаний. Оборотной стороной полезных для военного дела качеств оказываются не самые лучшие черты характера.
http://militera.lib.ru/bio/isaev_av_zhukov/index.html

Запрос: Левое внутреннее колесо основного шасси почти требует замены.
Ответ: Левое внутреннее колесо основного шасси почти заменено.
Запрос: Много мух в салоне.
Ответ: Мухи пересчитаны – количество соответствует.
Запрос: В наушниках невероятные шумы!
Ответ: Шумы доведены до более вероятных.
…

“Это отличная идея, – сказал пилот команды Формулы-1 “Ред Булл”, австралиец Марк Уэббер. – Я думаю, такая гонка обязательно должна быть. Но надо найти баланс между количеством освещения, поскольку оно должно отличаться от дневного света. Для этого необходимо провести тесты”.

Нееет. Это текст того цвета, который установлен у меня в настройках браузера как дефолтный для текста, на фоне того цвета, который установлен у меня в настройках браузера как дефолтный для фона 🙂
Есть разница?

Меня, собственно, вот что огорчает: любой человек, хоть раз в жизни занимавшийся оценкой коммерческой перспективы какого-либо подхода (способа, метода и т.д.), знает, что достоверная статистика составляется только при наличии и положительных, и отрицательных опытов. Рвать на себе рубаху с криками “да я блин десять лет делал сайты, и все работало!” это так же нелепо и глупо, как безымянное заявление на каком-нибудь форуме “за десять лет у меня было два жестких диска Samsung, и ни один из них до сих пор не сломался” по сравнению с официальной статистикой от сервис-центра “за десять лет мы поставили нашим клиентам более 2000 винчестеров Samsung, из них вышли из строя около 5 процентов”.

Практически все менеджеры проектов рано или поздно сталкиваются с явлением профессиональной апатии своих сотрудников. Впервые слово “конфигуратор” в подобном контексте использовал Роберт Шекли в своей известной фантастической повести “Необходимая вещь“. По сюжету, главный герой перед стартом космического путешествия вместо приобретения двух с лишним тысяч запасных деталей по контрольному списку – приобрел аппарат, мгновенно создающий любые мыслимые предметы и механизмы по первому же требованию. Но вот беда – лишь в далеких глубинах галактики обнаружилось, что разработчики заложили в машину черезчур много свободы воли, и ее искусственный интеллект отказывался производить более одной копии одного и того же предмета. Ему было скучно повторяться…

Синдром конфигуратора подстерегает всех тех разработчиков, которые достигли заметных результатов в своей профессиональной деятельности, но не достигли достаточного самоконтроля и самодисциплины. В каком-то смысле это напоминает йогу – развивая себя в творчестве, нужно развивать себя и в плане контролирования своих чувств, эмоций, желаний. Конечно, не до состояния зомби, в котором разработчик выполнял бы поставленные задачи как робот, но до тех пор, когда в его сознании сформируется баланс между реальными коммерческими целями компании и абстрактными задачами дальнейшего саморазвития.

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

Сотрудники, подверженные синдрому конфигуратора, вносят серьезные психологические “помехи” в работу коллектива. Им тяжело выполнять рутинные задачи, они с неохотой берутся за любые изменения, даже если речь идет про изменение к лучшему, даже просмотр старого кода (не говоря об исправлении) вызывает у них “ломку”. Хорошо, если благодаря структуре программного кода изменения вносить легко, но плохо то, что даже хорошо спроектированная система со временем воспринимается все хуже и хуже: разработчики нуждаются в “новой дозе”, мотивируя это тем, что “вот в этот раз мы уж точно напишем идеальную систему”. Результат известен многим руководителям: разработчики так увлекаются проектированием, что многие решения остаются только на бумаге: их не только не успевают, но и вообще не хотят претворять в жизнь…

Команда разработчиков доходит до абсурда: из-за крайнего нежелания переделывать вообще что-либо, сотрудники начинают требовать четко поставленного ТЗ и становятся неспособны к какой-либо аналитической или исследовательской деятельности, которая хоть на долю процента подразумевает выбрасывание части кода (вспомните известное утверждение: “всегда пишите первую версию с учетом того, что ее придется выкинуть в мусорную корзину”). В результате, вместо того чтобы использовать гибкие методики разработки (суть которых – с минимальными трудозатратами реагировать на изменения), разработчики начинают голосовать за четко поставленное ТЗ на годы вперед (что невозможно по определению) и начинают ненавидеть тех, кто вносит любые поправки в процессе разработки…

Синдрома конфигуратора можно частично избежать, если уметь четко ставить задачи (и воспитывать ваших заказчиков), а так же если сами по себе проекты, которые вы разрабатываете, действительно интересны и полезны людям. Но помните, что это лишь снимет симптомы: до истинных причин вам еще предстоит добраться.