Бэта должна выглядеть как бэта, а не как готовый продукт

Представляя бэту или прототип продукта, хочется его вылизать, чтобы он понравился клиентам. Это, наверно, на уровне инстинктов.

Такое редко бывает, но один пост перевернул мои представления о том, как должна выглядеть бэта версия. Точнее, даже не перевернул, а сформировал, т.к. я даже никогда не думала о проблеме бэта версий с такой точки зрения.

Клиенты воспринимают степень готовность ПО по степени готовности интерфейса.

Картинка из поста "Don't make the Demo look Done"

Вроде бы очень простая мысль, но она просто не приходила мне в голову раньше.

Если интерфейс выглядит законченным, то пользователи считают что продукт готов. В результате каждая последующая бэта будет восприниматься как затягивание релиза, а это неизбежно породит отрицательные эмоций в сообществе пользователей.

Интерфейс должен совершенствоваться в ногу с функционалом, тогда прогресс будет виден невооруженным взглядом, а пользователи будут довольны видимыми изменениями.

Конечно, можно сказать: "А на что history list? Все изменения можно посмотреть там". Но нравится / не нравится - это эмоция, которая возникает не зависимо от того, что написано в history list. Да и сам history list даже профессионалы при использовании сторонних продуктов не всегда читают. Обычные пользователи практически никогда ничего не читают - все должно быть понятно из интерфейса.

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

Готовность интерфейса должна соответствовать функциональной готовности продукта.

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

Новых вам интересных и успешных проектов в наступающем 2007 году!

Автоматизатор, автоматизируй себя сам

Среди более чем 400 примеров внедрения продуктов Microsoft исчезающе мало внедрений в сфере IT и среди них, в основном, телекоммуникационные компании.

Konstantin Starovoytov дал ссылку на Конкурс внедренческих проектов на iOne.ru. 39 компаний, в основном производственные, но нет ни одной IT компании-разработчика.

IT компании-разработчики, в общем-то, такие же компании, как и компании в других сферах деятельности. И у них есть все те же проблемы - есть свои бизнес- и производственные- процессы, документооборот, финансы, клиенты и т.д. И все это тоже надо автоматизировать. Но победных реляций о том что "мы сами себя так здорово автоматизировали, что у нас улучшилась производительность труда и поднялась отдача на сотрудника" не слышно.

Считается неприличным об этом говорить или IT-ки как сапожник без сапог - зарабатывают деньги на внедрениях другим, а у самих половина процессов завязана на личное общение, алгоритмы принятия решений покрыты мраком, и вся входящая почта в лучшем случае сканируется и складывается на чьей-то локальной машине?

Мне очень нравится проект виртуального офиса компании СладКо (описание на microsoft.com, описание на iOne). Первый раз я о нем прочитала примерно года 2 назад. Первой мыслью было – звучит очень заманчиво и слишком красиво чтобы быть правдой. А второй мыслью было – почему это сделала кондитерская компания, а не IT? Т.е. возможно есть крупные IT компании, существующие без офиса, но я о них, к сожалению, не слышала.

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

Отсутствие офиса снимает не только финансовую нагрузку на его аренду, но и сложность поиска нужных специалистов в одном месте. Например, Sergey Rozovik написал что в Дубну начали стекаться IT компании в связи с чем там резко подскочили зарплаты, но проблема не в этом, а в том что квалифицированных специалистов там не много, а спрос растет и, как мне кажется, основной проблемой там скоро станут кадры. Компании, не привязанной к офису, искать специалиста можно не в каком-то конкретном месте, а по всему русскоговорящему сообществу (а если нет ограничений по языку – то вообще во всем мире).

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

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

Меняет ли Web2.0 модель формирования нашего мнения?

Периодически выходят статьи и появляются посты что Web2.0 вытесняет традиционные издания и что с Web2.0 слишком много информационного шума. На счет "вытесняет" мне кажется это слишком преждевременно т.к. "людей, получающих всю нужную информацию из интернета" пока не так уж и много.

Но как влияет Web2.0 на тех, кто все-таки постоянно "подключен" (на нас)?

Меняет ли быстрый доступ к информации и большому количеству мнений модель формирования и изменения нашего собственного мнения?

Мне кажется, что по большому счету ничего не поменялось. Раньше были издания, мнению которых доверяли - теперь персоналии. Собственное мнение все так же формируется

• на основании своего опыта, а он (так уж обычно бывает), бывает глубоким в очень небольшом количестве областей
• на основании чужого мнения, которому доверяешь.

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

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

Web2.0 изменил способы генерации и доставки информации. Но потребитель остался таким же, каким и был.

Неудачные опыты с мобильным офисом

Переезд в теплые края закончен.

В связи с переездом появилось новые мироощущения и отпали начавшие прорезаться надежды:

Надежда (это та, которая умирает последней). Засунуть все рабочие данные в интернет, не держать ничего на локальном компе и ноуте, не таскать за собой массу информации и дистрибутивов при переездах, не мучиться с синхронизацией данных между компом и ноутом, и, в конце концов, перестать бегать с ноутом по интернет-кафе. На текущий момент одни только сервисы гугла уже практически покрывают основные потребности: почта – Gmail; офисные документы - Google Docs & Spreadsheets; RSS Reader - Google Reader; изображения – PicasaWeb. Есть еще масса сервисов от закладок до построения диаграмм и бэкапов. Все это очень красиво звучит, и некоторые уже так живут. И даже можно отбросить паранойю по поводу утекания приватных данных. Но есть проблемы, которые в очередной раз были испытаны на собственном опыте:

Во первых, интернет есть не везде, даже если он "условно" есть в каком-то интернет-кафе он может быть такого ужасного качества, что даже gmail грузиться отказывается.

Во вторых, если связь в интернет-кафе хорошая, то там (очень часто) стоят камеры на всех компах и благополучно пишут все пароли. Если с ноутом туда приходить то при наборе пароля клавиатуру хотя бы крышкой ноута прикрыть можно.

И в третьих, при работе с почтой из броузера нет спелчекера, в результате чего получаются подобные перлы и нет шаблонов ответов, без которых работается гораздо медленнее.

Ну и в четвертых, работать по 6 часов в интернет-кафе абсолютно не комфортно плюс никаких денег не напасешься.

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

Новое мироощущение же можно выразить так – прогресс sucks, оставьте все как было. Т.е. раньше у меня было устойчивое мнение, что если появляется что-то новое то оно приживается только если удобно потребителям. Покупка нового ноута и его дальнейшее использование опровергло это мнение напрочь. Ноут покупался с Core 2 Duo и в процессе выбора выяснилось что все свежие модели идут с зеркальной матрицей, исключение составляют (похоже временно) только дорогие Lenovo и HP. За ноутом с зеркальной матрицей работать невозможно – бликует и очень слепит. После часа работы глаза начинают болеть. Антибликовая пленка помогает несильно, плюс ее наклеить – это отдельная история. Но производители переходят на зеркальные мониторы т.к. они хорошо продаются. Они очень красивые, яркие, блестящие с сочными цветами и очень красиво выглядят на витринах. Производителю главное – продать, а то, что за таким ноутом работать невозможно его уже не интересует, это проблемы потребителя. Или, возможно еще не достаточно времени прошло и производители одумаются?

И снова о SOA

Так что же такое SOA. Сервисно-ориентированная архитектура. Вроде бы очень говорящее словосочетание. Но большинство копий в обсуждениях на ITBlogs поломались, по моему, о слово архитектура (не то, чтобы слово архитектура встречалось часто, но смысл баталий именно вокруг этого).

Что имеется ввиду? Я вижу 2 варианта и они очень разные.

• Архитектура как подход к проектированию системы
• Архитектура как подход технической реализации.

С точки зрения SOA как технической реализации, система проектируется как раньше, и реализуется как набор отдельных компонентов (они же сервисы). В данном случае, как мне кажется, SOA – это buzzword. Раньше это называлось модулями и интеграцией отдельных систем. Т.е. и раньше можно было взять системы разных производителей (если это было оправдано) и интегрировать их у себя. Система при этом не становится наборной, она остается единой, но собранной из отдельных модулей. Сейчас такие системы называют SOA. Почему? Просто потому что модный термин?

С точки зрения SOA как подхода к проектированию, получается наборная, постоянно модифицирующаяся, система – т.е. выявляется проблема, для ее решения делается сервис, выявляется другая проблема, для ее решения еще сервис. Сервисы друг для друга – черные ящики. Это очень облегчает проектирование системы. Тут самое сложное заложить основу взаимодействия сервисов. Механизмы взаимодействия сервисов хорошо описал Влад Боркус (плюс к посту есть не менее ценные комментарии).

Подобный подход в проектировании системы удобен

• Для сервисов, рассчитанных на конечного пользователя, когда каждый следующий сервис решает еще одну проблему пользователя и интегрирован с предыдущими сервисами. В основном это web сервисы, но могут быть и desktop приложения, дополняющие друг друга.
• Для небольших мобильных компаний, сфера деятельности которых позволяет быстро подстраиваться под изменяющуюся ситуацию. Таким компаниям не нужны крупные ERP, им нужны сервисы, которые можно быстро ввести в строй и начать использовать и так же быстро от них отказаться. Эти компании, в первую очередь, сам же IT сектор, а далее практически весь непроизводственный бизнес (услуги, торговля). Но, в любом случае остается ограничение по размеру компании (по количеству людей). Каким бы простым сервис ни был нужно время на обучение сотрудников, а с внедрением, растянутым на длительное время, теряются вышеописанные плюсы.

Есть ситуации, на мой взгляд, когда подобный подход к архитектуре категорически вреден. Это системы крупных корпораций со сложными, запутанными взаимосвязями. В этом случае, конечно, проще делать сервисы под отдельные части бизнеса, но правильнее делать единую систему. Это сложнее. Для этого придется распутать весь клубок бизнес процессов и утрясти все нестыковки. Но без этого вообще не имеет смысла браться за систему т.к. оставшийся бардак в бизнес процессах не даст выигрыша бизнесу. Кардинально отличающийся взгляд на эту проблему здесь, у Даниила Фейгина.

Agile Testing

Очень интересные доклады по Agile методологиям на Google Video. Их довольно много. Вот некоторые (ссылки на остальные видны справа при просмотре):

• Agile Testing (Elisabeth Hendrickson)
• Scrum et al. (Ken Schwaber)
• Kent Beck: Ease At Work (В 7-и частях, к сожалению 1-ю не нашла, эта вторая. При просмотре рядом ссылки на остальные части)

Я пока осилила только Agile Testing. Очень зажигательная докладчица. Elisabeth Hendrickson является консультантом по software testing, основателем Quality Tree Software. На сайте Quality Tree Software есть документы с советами по тестированию продуктов и по набору тестировщиков. Ну и, конечно же, Элизабет ведет блог - Ruminations.

Разработка, идущая от тестирования, для меня, наверно, самая близкая из agile техник.

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

А разработка конечнопользовательских продуктов может идти от тестирования с самого начала. Здесь приложение решает проблему (или набор проблем) пользователя и нет четких рамок как это должно происходить – главное, что бы проблема решалась наиболее удобным для пользователя способом. Т.ч. проект сразу начинает жить подстраиваясь и видоизменяясь.

На текущий момент отдельные части кода, объекты и функциональные модули тестируются с помощью UnitTest-ов (которые встроены сейчас практически во все среды разработки). Практика эта довольно распространенная, хотя к порядку использования UnitTest-ов есть вопросы – кто и в какой последовательности должен писать тесты к коду? Должны ли сначала писаться по спецификациям тесты, а потом код? Должен ли сам программист писать тесты к своему коду? У меня пока нет универсального ответа, пробовались разные варианты и у всех есть свои недостатки.

Но основной проблемой тестирования является проблема комплексного функционального тестирования проекта. В основном сейчас это делается вручную. Но, особенно для корпоративных систем, это очень трудоемко и, довольно часто, требует знания предметной области.

Однако даже если найден способ тестирования интерфейса, от ручного тестирования не уйти. Именно оно помогает выявлять проблемы интерфейса и модели поведения пользователя, что позволяет улучшать проект.

technorati tags: Agile Testing