Роботы против людей

Когда-то люди научились создавать первые механизмы, вроде автоматонов Жака Дро (Jaquet Droz). Эти машины умели играть на музыкальных инструментах, писать пером письма на бумаге (не забывая макать перо в чернильницу).
Выглядели они примерно так:

Вот тут по ссылке более подробная статья с фотками и роликом.

Всеобщая одержимость механическими устройствами была отражена даже в сказках. Перечитайте, кто не помнит, сказку «Свинопас» Г.Х. Андерсена — принцесса и фрейлины очень разочаровались, узнав, что роза и соловей «настоящие».

Создав первые механические устройства, люди увидели что это хорошо и начали мечтать о машинах-роботах, которые будут надежными помошниками человека. Что-то вроде «начинки» кабинета Тони Старка из «Железного человека» (смотрите с момента 1:15).

Потом, правда, в умы людей попало зерно сомнения и люди стали бояться роботов, полагая, что люди попадут под власть роботов, как более сильных, умных и организованных созданий. Даже фильмов поснимали вроде «Терминатора» и «Матрицы».

Но, как лично я много раз убеждался, страх — материален. Если чего-то боишься, оно обязательно случится. И попадание человечества под власть роботов тоже произошла. Вот, например, как собирается самый современный на данный момент автомобиль «Тесла»:

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

Ещё сомневаетесь, что роботы победили?

• Посмотрите на более-менее современную кофе-машину. Она вполне себе командным тоном указывает человеку, что он должен сделать:
• Долейте воды в бачок
• Досыпьте кофе
• Очистите контейнер для гущи
• Нажмите «Очистка»
• Установка программы на компьютер
• Нажмите 10 раз далее
• Согласитесь с условиями лицензии
• Снимите галку с установки «Яндекс-бара»
• Любимый смартфончик
• Его нужно зарядить
• Программки обновить
• Будильники вовремя снять/установить (иначе он в среду 1 января в 6 утра вас подымет с кровати, хотя производственный календарь известен за несколько месяцев до нового года)
• Посмотрите, как многие начинающие (и не только!) программисты разрабатывают взаимодействие с пользователем
• Пришлите нам этот отчет и информацию о том, как вы эту ошибку воспроизвели
• Обратитесь к администратору, чтобы...
• «Ошибка связи с базой данных» (моё любимое сообщение, оно всегда мне помогает ;)

Вы ещё считаете себя венцом творения? ;)

Взять и переписать!

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

Две профессиональные цели я тогда для себя определил — снова поучаствовать в профессиональном обучающем мероприятии (до этого я один раз участвовал на User Group) и сделать для своих продуктов систему автоматического обновления.

Первая цель трансформировалась через какое-то время в организацию в Таганроге конференции Стратоплана.

Вторую включил в график билдов, в начале года дошло дело до неё и тут случился интересный повод порефлексировать.

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

Да, и на старуху бывает проруха — я чуть было не стал жертвой этой второй болезни. Вовремя спохватившись, сперва покопался в интернете и нашел несколько платных библиотек, несколько бесплатных, какие-то поделки на codeproject и остановился на одной из них - NetSparkle. Интересная штука, простая, локализованная. Поискал её на NuGet, попутно нашёл ещё одну, похожую — AutoUpdater.Net. Дальше уже всё по писанному:

1. Перелопатил ещё раз NuGet, ничего более интересного не нашёл.
2. Создал тестовое решение с двумя приложениями, реализовал их обновление через обе библиотеки, проверил.
3. В результате NetSparkle завести толком не смог, ни свое прилоожение, ни пример из их исходников — ругается, что подпись не родная и хоть ты тресни. Причем окно с этой руганью локализовано так, что надписи не вмещаются в диалоговое окно.
4. На проверке актуальности файла мне свет клином не сошелся, а второе решение работало вполне понятным образом, обновлялось и с сайта и по локальной сети.
5. Тем не менее, в AutoUpdater.Net был без локализации и нашёл один небольшой баг — библиотека брала название приложения не из атрибутов сборки, а из имени сборки (программисты, блин!). Качнул исходники, сделал из них репозиторий Mercurial, локализовал библиотеку, починил баг, связался с автором библиотеки, он изъявил интерес к моим изменениям, сделал дифф и отправил ему. Пара часов и инстинкт программиста удовлетворен по полной!

Выводы:

1. Реюз — страшная сила! Сам бы я с нуля писал это дело гораздо дольше.
2. Все приемы управления проектами основаны на практике и до них можно дойти самостоятельно, но проще и дешевле вдумчиво почитать умную книжку, там уже почти всё есть (реюз опыта) ;)
3. Если у вас есть программист — любитель покодить, предложите ему усовершенствовать готовый опенсорсовый инструмент или сделать свой опенсорсовый проект. Это мотивирует в разы сильнее, чем просто сделать что-то для проекта, что заказчик даже не увидит (мне, почему-то, шедулеры достаются часто).
4. DVCS — рулит. Процесс получения диффа быстрый и легкий — все утилиты уже встроены и не нужно инфраструктуру создавать.

P.S. Для тех, кто дружит с английским рекомендую послушать подкаст Скотта Хансельмана про GIT. http://hanselminutes.com/350/learning-how-to-learn-git-with-michael-sarchet В начале, при обсуждении Mercurial гость, который "использовал Mercurial 2 месяца" упоминает одну фишку, которой ему очень не хватало. Я, как человек, который работает с Mercurial почти три года, скажу, что это есть и делается довольно просто ;)

Чем пахнут ремесла

На днях довелось понаблюдать за собеседованием программистов-железячников, занятно было порефлексировать, понаблюдать что я ещё помню из языка С и особенностей реализации компьютеров. Узнал для себя забавное понятие Cache-oblivious algorithm, много думал ;).

Но поводом для написания этого текста стало немного другое. Во время этого собеседования я с особой четкостью осознал, что знание аппаратуры, конечно, может помочь выйти из top-10% профессионалов в top-5%, но в большинстве случаев не является существенно важным навыком.

После некоторых размышлений я описал свою работу примерно так. Большую часть времени я занимаюсь "заградительным" программированием. Мой код должен быть написан таким образом, чтобы другой разработчик (или я через несколько месяцев), надумав что-то в коде поменять, мог быстро определить где вносить изменения, какие именно, и что ещё будет затронуто изменением. А ещё чтобы было очевидно что делать ни в коем случае нельзя. При этом я не могу использовать такие ресурсы как ТЗ, спецификации, любая документация и, зачастую, даже комментарии в коде, потому что они наверняка не обновляются вовремя и, как следствие, им всё равно никто не доверяет. Поэтому для сколь бы то ни было сложной задачи мой код должен выглядеть очень простым и понятным. И если вдруг потенциальный работодатель попросит меня предоставить кусок кода как часть резюме, то мой код будет выглядеть как пособие к лабораторной работе на 3-м курсе. Все более-менее нетривиальные куски кода будут реализацией подходящего шаблона проектирования, причем, скорее всего, код написан не мной, а выбран после тщательного изучения нескольких вариантов на хабре, codeproject и stackoverflow. Либо будет использована подходящая библиотека с nuget, тоже после тщательного изучения примеров использования и реализации пары тестовых приложений.

Вот список вещей, которые я считаю важными для разработки прикладного софта:

1. Знать своего пользователя.У нас никогда не будет 100% корректных и неизменных требований. Это знание включает в себя знание его работы, опыта работы с компьютером, привычек, окружения.
2. Поскольку знать клиента на 100% тоже нельзя, то уже много лет в каждом продукте у меня встроен мониторинг сбоев. Для веб-проектов это Elmah, для десктопа — честно позаимствованный из интернета и немного модифицированный набор классов. А после релизов день начинается с разбора присланных логов.
3. Строгое следование принципам KISS и YAGNI. Иногда (всегда?) немного в ущерб производительности и требованиям к ресурсам.
4. Как можно меньше изобретать новых алгоритмов и подходов.По максимуму использовать идеи тех гигантов, на плечах которых мы стоим.
5. Очень внимательная работа с архитектурой решения. Архитектура должна быть по возможности примитивной, но позволять менять и расширять её в широких пределах, в то же время оставаясь достаточно производительной и с минимумом зависимостей. В идеале новому программисту архитектуру можно нарисовать на салфетке в обеденный перерыв.
6. Оценивать свои усилия в соответствии с известным законом и выдавать первый прототип как можно раньше.
7. Паранойя, паранойя и ещё раз паранойя. Что-то обязательно сломается прямо перед релизом, что-то сразу после, или на презентации/демонстрации. на половине машин продукт просто не заработает без всяких сообщений. Пользователи обязательно будут использовать продукт совсем не так, как надо, не будут видеть большую кнопку в центре экрана, которую нужно нажать, а будут жать на всё то, что программист забыл спрятать. Если пользователя спросить, какие действия привели к ошибке — он переврёт 20% информации, а оставшиеся 80% не будут относиться к проблеме. Начальные требования формулировал человек, который не в теме, а после релиза громче всех будет настаивать на их изменении тот, кто не имеет полномочий. Ну, а следующий же программист, который будет участвовать в проекте после меня — просто всё сломает, а я забуду все детали этого проекта как только начну работать над следующим.

В этом плане поучительный фильм про нашу работу — это "Доктор Хаус". Все врут. Только когда пациенту станет совсем плохо, можно поставить точный диагноз. А симптомы в большинстве случаев, основательно замаскированы разными аллергическими реакциями кода на производственную среду или отладчик.

Как следствие, есть языки, которые более предпочтительны для прикладной разработки (Delphi, Visual Basic и C#) просто потому, что большая красная кнопка в них спрятана подальше, чем в C и C++.

А что важно в вашей профессии? :)

Чем живет ваш пользователь?

Обсуждали недавно с коллегами почему Микрософт убрал из студии сравнение данных в двух базах и упорно не возвращает эту функцию назад.

1. Да, есть много готовых продуктов, которые предоставляют такую функцию, но они платные и непонятно зачем покупать ещё один продукт, если уже куплена студия.
2. Да, можно сделать скрипт руками и сравнить данные. Я даже когда-то давно делал так эффективное сравнение данных между географически распределенными серверами с медленным каналом. Но это нужно каждый раз со скриптом возиться.
3. Да, можно этот скрипт обернуть в красивый интерфейс, что потребует относительно немного времени. Но почему это небольшое время не может потратить разработчик Микрософта, вместо того, чтобы каждый сам себе ваял скрипт или утилиты сравнения данных?

Сразу на память пришла цитата из биографии Джобса:

Однажды Джобс заглянул в кабинку к Ларри Кеньону, инженеру, разрабатывавшему операционную систему Macintosh, и пожаловался, что она слишком долго грузится. Кеньон принялся было объяснять, но Джобс перебил: «А если бы от этого зависела чья-то жизнь, вы бы придумали, как сократить время загрузки на десять секунд?» Кеньон ответил, что постарался бы. Тогда Джобс написал на доске расчеты и продемонстрировал Ларри, что если бы пять миллионов человек использовали Mac и каждый день им  приходилось бы загружать его лишние десять секунд, в год получилось бы около 300 миллионов часов, что равняется примерно 100 жизням, которые в противном случае можно было бы спасти. «На Ларри это произвело впечатление, и через несколько недель он добился результата: система стала загружаться на 28 секунд быстрее, — вспоминает Аткинсон. — Стив умел мотивировать сотрудников, преподнося ту или иную проблему в глобальном смысле».

Отрывок из книги: Айзексон, Уолтер. «Стив Джобс.»

Что-то всё-таки, в королевстве датском не так. Похоже, МС перестал ощущать масштаб самого себя.

Летний набор в клубы профессионального и карьерного роста

Друзья, 11 июня открывается регистрация на клубы профессионального и карьерного роста Стратоплана.

Я сам участвовал в клубе переговорщиков, что дало возможность решить ряд проблемных ситуаций по работе. Мой знакомый, который делает ремонт у себя в квартире, после клуба улучшил для себя условия договора и в значительной мере окупил участие в клубе.

Кому тема интересна, можно успеть получить некоторое количество бесплатных слонов.

Каждый студент клуба получит:

• 3 месяца практической работы
• 12 тематических уроков
• Домашние задания по каждому уроку
• Обратную связь от ведущего клуба
• Пожизненный доступ в закрытый форум клуба
• Пожизненный доступ ко всем гостевым и дополнительным семинарам своего клуба
• Пожизненную скидку 30% на участие в любом клубе Стратоплана
• Возможность участия в переговорных поединках Стратоплана
• 20 часов дополнительных мастер-классов по менеджменту, бизнесу, коммуникациям и управлению проектами

Первые 100 студентов получат возможность:

• Участия в "Скучном семинаре" - 6 часов работы с собственными целями, которые повысят эффективность обучения в 2 раза
• Участия группы до 15 человек от вашей компании в любом из 4 семинаров СТРАТОСФЕРА июня-2013

Подпишитесь на сайте, чтобы получить ссылку на регистрацию раньше остальных.

"Открытость или фрагментарность" против "контроля" — два подхода к проектированию

Продолжаю читать книгу Уолтера Айзексона "Стив Джобс" и заряжаться идеями из опыта этого замечательного человека.

На днях с коллегами обсуждали подходы телефоностроителей к построению интерфейсов и выявили забавное различие:

1. iPhone — двойное нажатие на "кнопку на морде телефона". Чтобы закрыть приложение, нужно подержать палец на иконке и позакрывать ненужные крестиком.
2. Android — нажать и подержать кнопку "Home". Чтобы закрыть приложение, нужно подождать, пока операционка не закроет его сама. Ну, или поставить специальную программу (чтобы закрыть её, нужно ждать, пока операционка не закроет её сама).
3. WindowsPhone — нажать и подержать кнопку "Back". Чтобы закрыть приложение, его нужно выбрать и нажать "Back". Кстати, ещё вопрос — какой процент пользователей знает про такие сайд-эффекты (кстати, статья про этот термин в википедии помещена в раздел "Ошибки программирования").

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

В ходе нашего обсуждения мы решили, что основаниями для такого решения были следующие моменты:

1. Нажать и подержать кнопку "Home" вызывает голосовой ввод. Довольно типичный приём, кстати.
2. От использования двойного нажатия на кнопку "Home" отказались, судя по всему, из-за того, что кнопка может быть сенсорная и будут сложности с отслеживанием двойного нажатия.

Вот тут и всплывают во всей красе недостатки "фрагментарности", за которую Джобс укорял в своё время Андроид и которые в полной мере применимы к WindowsPhone. Думаю, лучше всего мнение самого Джобса могут выразить очевидцы:

Джобс создавал Macintosh для массового потребителя и не хотел, чтобы пользователи меняли что-то в компьютере. Джобс хотел контролировать то, как потребитель использует его продукцию. «В этом весь Стив с его стремлением к контролю», — рассуждает Берри Кэш, которого Джобс в 1982 году взял в Apple стратегом по маркетингу «Башни Texaco». Стив жаловался, что в Apple II «мы ничего не контролируем: пользователи меняют компьютер кто во что горазд. Больше я такой ошибки не совершу». Он даже поручил команде разработать специальные инструменты, чтобы корпус Macintosh нельзя было открыть обычной отверткой. «Мы сделаем все для того, чтобы никто, кроме сотрудников Apple, не смог залезть в компьютер», — говорил он Кэшу.

 (Отрывок из книги: Айзексон, Уолтер. «Стив Джобс.»)

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

Блеск и нищета бизнес-образования

В Inostudio есть хорошая практика — сотрудники выступают с тематическими докладами перед коллегами.

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

Немного погуглив я нашел источник этой информации. По сути, речь идет о модном направлении в менеджменте — business unit.

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

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

Но самый, на мой взгляд, яркий пример такого стиля управления я прочитал в книге "Правила Джобса" (Кармин Галло):

В качестве примера Брасс рассказал, что технологии под названием ClearType (метод улучшить читаемость текста на экране компьютера) понадобилось десятилетие, чтобы пробить свой путь из лаборатории в Windows. По его словам, другие команды Microsoft чувствовали «угрозу от нашего успеха». Брасс и его команда создали планшетный ПК в 2001 году, но вице-президент, ответственный за Office в то время, решил, что ему не нравится концепция. Он отказался внести поправки в приложение Office, дабы оно должным образом работало на планшете, по сути, обрекая проект на провал. Команда Microsoft, работающая над планшетом, была распущена. Это грустная история. Междоусобная война потопила проект, на развитие которого ушли сотни миллионов и который мог бы сделать Microsoft одним из ведущих новаторов в новой и захватывающей категории мобильных компьютеров.

Чтобы подтвердить аргументы Брасса, я встретился с Тимом Баджарином, ведущим аналитиком и экспертом Apple. «Большая разница между компаниями заключается в том, что в Apple все заодно, ведомые Стивом Джобсом. Это значит, что каждая команда и каждый проект идут в ногу с идеей Джобса, — сказал Баджарин. — Предприятия Microsoft — это бункеры, и все они — подразделения, самостоятельно получающие прибыль. Во многих случаях правая рука не знает, что делает левая. Планшет — хороший тому пример.

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

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

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