Нет-нет, статья не про план резервного копирования. Статья про план «Б».
Поддавшись массовой истерии, решил я перейти в НПФ. (Нет! Статья не про НПФ!)
Почитал обзоры и рейтинги, выяснил, что разные источники без зазрения совести публикуют разную доходность по одним и тем же НПФ (опять отвлекаюсь)… и решил перевести в ХХХ24 (нет смысла обсуждать).

Прихожу в отделение, сижу с талончиком 1 час (один час) в очереди из трех человек, наконец попадаю на приём и выясняю, что «у нас сегодня система висит и почти не работает». (Вот! Вот про это статья.)
Ну что ж, я понимаю, бывает.
Через два дня, в эту пятницу, я прихожу в другое отделение ХХХ24 и уже совершенно без очереди узнаю, что у них тоже система «висит и не работает». И нет, без системы они не могут принять заявление.
— Как же так? — говорю — Все отделения что-ли не работают?
— Вот в понедельник ещё всё работало нормально. Вы приходите на следующей неделе.
Я даже на минуту задумался, когда у меня на следующей неделе будет возможность уйти с работы, чтобы прийти в банк, но тут же меня осенило:
— Нельзя в такой банк переводить свои деньги!

Нет, это не реакция капризного ребенка. Да, системы, бывает, глючат. Но как себя ведет этой ситуации банк и НПФ? А никак. Они ничего не делают. У них нет плана «Б».
Как раз в те дни, когда всплеск активности переводов в НПФ.
А ведь это не мгновенные переводы, тут система вообще не нужна. Им достаточно принять от меня заявление с подписью, с правильно заполненными реквизитами, с бесполезной ксерокопией паспорта и СНИЛС-а, чтобы потом отослать его в пенсионный фонд и завести в систему.
То есть, где-то в банке сидит большой человек, ответственный за НПФ, получающий бонусы за его успешность, но ему пофигу, что клиенты несколько дней не могут написать заявления.
А ведь мог бы построить всех, разослать хоть по электронке, хоть курьером инструкции по приему заявлений в бумажном виде, отправил бы бланки для заполнения и процедуру, как их потом вводить при восстановлении работоспособности. Понятно, не сам, через подчиненных. Но он не делает этого.
Могу я быть уверенным, что когда нужно будет быстро отреагировать на изменения на рынке и перевести мои инвестиции из одних финансовых инструментов в другие, этот банк сможет быть эффективным?
Нет. Я не уверен.

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

Пример 1: на заправке Газпромнефть мне выдают 6 (шесть!) чеков.

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

Да, тут даже можно проследить логику. Но зачем мне такая логика? По вечерам на заправке очередь, а все эти махинации занимают лишнее время.
Особенно поражает размах бумажной щедрости после поездки в Норвегию, где самые богатые и бережливые жители мира обязательно спросят: нужно ли мне печатать чек об оплате. Бумага, чай, не бесплатная.
Я знаю, наш мир тесен — вы передайте обязательно разработчикам, что так делать не надо.

Пример 2: прорывной сервис онлайн покупки билетов РЖД.

Хочу поделиться своей мечтой. Напишу сразу всю суть идеи, а потом углублюсь в детали.
Я бы хотел, чтобы существовала система для создания и эксплуатации автономных любительских исследователей Земли.
Вдохновлена эта мечта марсоходами, «Солнечным импульсом», «Исследователем океана», Платформой Ветер и статьями про марсоход в коробке.
Сейчас уже возможно создать автономный модуль с источником на солнечных батареях, который сможет достаточно долго плавать в океане, парить в воздухе, ездить в пустыне, исследовать Антарктиду и другие малообитаемые стихии, оставаясь при этом на связи с группой своих пользователей (назовем их «навигаторами»).
Навигаторам доступна система управления проектом, включая контроль бюджета, стратегических и тактических целей, технический, экологический и социальный мониторинг.
Я мечтаю о такой машине с детства. С запасом энергии, с источником электричества, с панелью управления агрегатами, с запасом живучести и автономности. И с возможностью посоветоваться с друзьями, распределить работы, а потом поделиться собранными материалами.
Понятно, что электронная и системная начинка могут быть универсальными, а шасси должны адаптироваться под выбранные среды. Робот передвигается, фотографирует и измеряет окружающий мир, передает на сервер собранные данные. Навигаторы обрабатывают данные, планируют миссии, занимаются управлением, пишут в блог исследователя, делят прибыль от рекламы ;-)

Вот мне попался фрагмент дневника одного из Навигаторов:

Утром, за чашечкой кофе, вместо газеты я включил платшетник и убедился, что за световой день аккумулятор моего пустынного посланника на другой половине планеты подзарядился до 83%, а значит можно включить назад вырубившуюся камеру ночной съемки, охлаждаемую элементами Пельтье, и запустить автофото от датчика движений. Есть надежда поймать неизвестных ночных жителей: студенты-энтомологи очень просили. Они до сих завидуют соседям с зоологического с фотками подкустовного выползня, который приходил обнюхивать пустынника.
А вот мой северный «Солик», как его окрестили фанаты, похоже, переживает тяжелые времена. Штормит, пасмурно, солнце низко, он давно без движения болтается на поверхности, за день тусклого света хватает лишь на сеанс связи и минимальный обогрев аккумуляторов. Хорошо, он хоть в термоизоляционном исполнении, но ведь выходит на связь все реже и реже, и я уже жалею, что согласился послать его в заполярье. Программа кратчайшего и срочного возврата в более теплые широты уже отправлена, но он же который день не включает двигатели и экономит каждый милливатт. Я очень надеюсь, что солнце просветит раньше, чем промерзнут дешевые аккумуляторы. Эх, иметь бы РИТЭГ ватт на 10!
В очередной раз смотрю на небольшой список оставшихся потребителей тока. Наконец, решаюсь, что можно отключить GPS, весь модуль навигации с маячком. Всё равно, пока не зарядится, эта информация бесполезна..."

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

Наземный робот	Летающий робот	Плавающий робот
Колесный или гусеничный. Предназначен для езды в пустыне.	Легкий самолет с большой поверхностью крыла и аккумуляторами.	Плавает в нейтральных водах открытого океана. Монолитный герметичный монокок с солнечными панелями под защитным пластиком.
Наиболее дешевый и простой вариант, не боится остановок, но уязвим для вандализма.	Наиболее дорогой и сложный вариант. Очень уязвим к ошибкам пилотирования и неблагоприятным условиям, скорее всего будет запрещен.	Способен погружаться и осуществлять подводную съемку. В аварийном режиме всплывает и заряжается до восстановления работоспособности.

Итак, плюсики за статью типа "Платите программистам много" собраны, теперь самое время поговорить о том, почему это не работает просто математически, и что скрывалось за самым мелким шрифтом.

Понятно, почему это работает: распределение количества вакансий по зарплатам у нас очень похоже на нормальное, а значит у тех, кто находится справа от средней зарплаты, намного меньше возможностей найти зарплату выше, чем у тех, кто в левой части удава. Именно поэтому я написал, что ВЗ хоть и не мотивирует, но хорошо удерживает на текущем месте работы.
Но могут ли все работодатели воспользоваться этой «новой» и «работающей» методикой?

Эпиграф: Зарплата у меня хорошая, но маленькая!

Глядя на то, как появляются и исчезают в черновики вместе с комментариями и обсуждениями статьи о найме и удержании сотрудников, я тоже решил рискнуть.
Я хочу поспорить с тезисом о том, что деньги не мотивируют и высказать свои аргументы в пользу высокой заплаты.
Вот тезисы, которые я хочу раскрыть немного подробнее в статье.
1. Высокая зарплата не мотивирует. А вот низкая зарплата демотивирует сама по себе.
2. Высокая зарплата отрезвляет, так как хорошо понимаешь, что на такую позицию быстро найдутся желающие.
3. Высокая зарплата затрудняет переход в другое место.

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

Хочу описать и опубликовать идею, которая ещё не реализована, но которую невозможно реализовать самостоятельно.
Сейчас у нас есть множество рынков приложений — Windows Store, Google Play, Apple Store, Opera Mobile Store, Luzhniki Marketplace, etc. Однако, приложения для этих рынков могут создавать только программисты.
Мне видится, что в мире есть много экспертов, которые могут обучить желающих различным знаниям и навыкам, а также много этих желающих, готовых за 0.25 доллара просто и доступно научиться чему-то новому и интересному.

Идея в том, чтобы создать инструмент для экспертов без опыта программирования, позволяющий создавать обучающие приложения с функцией завершающего контроля знаний. Эксперт какой-то предметной области использует визуальный инструмент (аналог PowerPoint или даже конвертор из PowerPoint) для создания небольшого обучающего курса и завершающего экзамена (с автоматической или ручной проверкой результатов). Обучающее приложение упаковывается и становится доступным для загрузки на устройства покупателей. Для каждой из платформ реализуется единый плеер приложений, который также является клиентом для Knowledge Market (рабочее название проекта). Клиент обеспечивает расшифровку, офлайновую работу обучалки, платежи, интеграцию с соцсетями и прочими сервисами.
Рынок обеспечивает рейтингование, отзывы, обзоры, рекламу курсов, бесплатные пробники, партнёрские и корпоративные программы, курсы на заказ и т.д.

Сравнение	<Platform> Store	Knowledge Market
Аудитория	Пользователи платформы <Platform>	Пользователи всех платформ
Разработчики	Разработчики платформы <Platform>	Эксперты предметной области
Порог вхождения	Высокий	Низкий
Разнообразие изобразительных средств	Неограниченное	Ограниченное

Уж скоро года два минет, как я так и не реализовал одну идею. Уже пришли другие, успели остыть, уйти и уступить более новым, а эта — осталась. Мне не хватает такого реализованного инструмента, поэтому я решил описать идею публично и надеяться, что мне подарят лицензию на первую профессиональную версию, а со второго миллиона прибыли поставят бутылочку хорошего коньяку. =)
Идея проста: я предлагаю скрестить систему управления задачами (To-Do List) с системой ограничения сетевого доступа:

• Нет важных задач — гуляешь по хабру, играешь в блек-джек, смотришь девушек.
• Есть важные задачи — не пускают к блек-джеку и девушкам, но сам хабр пока не ограничивают.
• Истекает срок важных задач — пускают только в поисковик, msdn и stackoverflow, отключают мессенджеры.

Кстати, название этой системе я тоже дарю: ConcentrateOn (произносить как concentration).

В своей работе мне довольно часто приходится обсуждать вопросы подходов к учету времени, потраченного на разработку программного обеспечения. Нужно ли учитывать время по каждой задаче? Нужно ли отчитываться каждый день? Полезны ли «таймшиты» и как они должны выглядеть? Кто должен заполнять отчёты и когда? И т.д. Иногда разговор уходит к противостоянию Agile-методологий и более строгих методов управления.
Бывает, такие обсуждения переходят в спор, противостояние точек зрения, а заканчиваются примиряющей фразой: «конечно же, каждая компания имеет свою специфику и особенности, свою модель бизнеса, а значит и свои подходы к учету ресурсов». И это правильно, потому что, по большому счету, принципы учета ресурсов зависят от модели бизнеса, но я всё же хочу собрать в одном месте накопленные аргументы разных сторон и подходов, а главное — попробовать сделать «открытую статью», статью в виде диалога, в виде противостояния аргументов и точек зрения, на которую повлияют комментарии и голоса читателей.
На мой взгляд, различные варианты сводятся к трем базовым подходам:

1. Учёт потраченных человеко-часов с разбивкой по задачам
2. Учёт реализуемого функционала (backlog/requirements) и общая оценка стоимости работ
3. Творческая работа без списка функционала и контроля ресурсов

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

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

Обсуждать и противопоставлять мы будем первые два подхода, потому что про третий я рассуждать не могу. Мне приходилось работать в разных компаниях и в разных проектах, на разных технологиях и в разных управленческих схемах…
И самые интересные, технологически сложные и продвинутые, самые необычные проекты делались именно по третьему подходу. Именно про эти проекты я рассказывал на собеседованиях, именно в них создавались принципиально новые продукты, а не всякая надоевшая обыденность типа база данных→бизнес-логика→бизнес-процессы→клиентские представления→отчёты. Работой в этих проектах я горжусь, вспоминаю с ностальгией, не стесняюсь сказать «вот эти архитектурные решения принял я», и именно про эти проекты обычно слушают с большим интересом. Но с другой стороны, именно эти проекты были очень дорогими и экономически сомнительными. Сейчас никакие аргументы за или против таких проектов я приводить не готов, поэтому рассмотрим только два подхода:

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

Требования к инструменту

На мой взгляд, такой инструмент должен:

1. Быть интегрирован с системой баг-трекинга, чтобы можно было заводить дефекты по мере их обнаружения
2. Автоматически документировать обнаруженный дефект. Это важно, когда тест идёт не по сценарию, а в произвольной последовательности, которую невозможно держать в голове
3. Обеспечивать возможность повторения последовательности исследовательского теста
4. Быть интегрирован с системой управления требованиями — чтобы по возможности привязывать обнаруженные дефекты к требованиям
5. Быть интегрирован с системой управления тестами, чтобы:

• проводить все виды тестирования в единой среде
• создавать новые сценарии тестирования на основе исследовательских тестов

Собственно, оптимальным вариантом в этом смысле будет наличие поддержки исследовательского тестирования в интегрированном инструменте управления требованиями, тестами и дефектами. Об одном из таких инструментов — Microsoft Test Manager 2012 — я и хочу рассказать.
В 2012-й версии MTM появилась поддержка исследовательского тестирования. Способы применения этого функционала мне видятся следующие:

1. Проведение исследовательского тестирования в дополнение к тестам по сценариям
2. Проведение тестирования в условиях отсутствия сценариев тестирования
3. Быстрое создание новых сценариев тестирования через сеансы исследовательского тестирования

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

Например, может ли такой разум определить скорость света? Или материал процессора? Попробуем мыслить подобным образом, почувствуем себя физиками – наша задача изучить строение мира, находясь «внутри» этого мира.
upd: для полноты картины, находим место для религии и её формы.
upd2:в качестве примера, придумайте, как с помощью вычислений на процессоре подтвердить теорию корпускулярного строения вещества процессора?

Давайте обсудим вопрос организации иконок на рабочем столе. Хочется сказать: «покажи мне свой десктоп, и я скажу, как ты работаешь». Вынесу вверх главную мысль: Рабочий стол предлагается использовать для организации текущей работы над документами. Что на столе — то в сознании, в фокусе. Поэтому важно иметь структуру этого фокуса и важно вовремя убирать из фокуса лишнее.
Часто можно наблюдать следующие стратегии поведения при использовании рабочего стола:

• заполнить стол значками до предела, периодически «удалять неиспользуемые»
• оставить на столе корзину и красивую картинку, удалять со стола всё, регулярно чистить корзину
• расположить на столе часто используемые ярлыки и некоторые рабочие документы

UPD: Пока в комментах побеждает вариант неиспользуемого стола.
Всё это — варианты нормы, единственный недостаток — рабочий стол не помогает в организации работ. Это примерно как обвинить кота, что он не приносит тапочки. Но ведь мог бы и приносить!!! Достаточно правильно расчертить дорожки.

Сначала я подумал, что я гений и заработаю миллионы на этой идее, но потом решил вбить в поисковик «Organizing desktop wallpaper». Нафантазированная яхта и девушки-поклонницы исчезли, но стало ясно, что, во-первых, желание вполне адекватное, а во-вторых уже есть готовые варианты, чтобы взять и использовать. Т.е. хотя бы тапочки. Картинка выше взята из статьи How to Design and Create a Clean, Organized Desktop.
Ниже будет список найденных статей и вариантов, а также я расскажу о своей идее и тех задачах, которые она должна решать:

Давайте познакомимся с новыми инструментами планирования, появившимися в TFS 11 Beta, которые можно использовать в разработке Windows, Web, мобильных, облачных и кросс-платформенных приложений.



Так как TFS позволяет использовать несколько шаблонов процессов для поддержки разных методологий организации процесса разработки, мы сначала рассмотрим только один из них, наиболее популярный SCRUM.
Для знакомства нам могут понадобиться: образ виртуальной машины, руководства к лабораторным работам, практическое занятие на русском MSDN или данная статья – на выбор.

План захвата темы:
• Описание требований (Backlog)
• Планирование итерации
• Планирование работ
• Загруженность исполнителей