5 составляющих хорошего пользовательского интерфейса

Из чего состоит качественный, дружелюбный к пользователю интерфейс? Для себя я выделил 5 составляющих.

1. Насколько быстро можно обучиться работе с интерфейсом? Одно дело, когда смотришь на окошко и сразу же понимаешь, что здесь к чему, и совсем другое – когда нужно почитать мануал. Разница во времени – порядки. Этот параметр особо важен для сайтов. Ещё Стив Круг подметил, что сайты никто не изучает. В самом лучшем случае их просматривают, бегло и по диагонали.
2. Насколько быстро пользователь может решать свои задачи при  помощи интерфейса? Одно дело, когда для выполнения операции нужен один клик, другое – что-то набрать в командной строке. Во втором случае вам необходимо вспомнить название команды, её параметры, да ещё и набрать кучу символов на клавиатуре. Не подумайте, что я противник командной строки, ровно как и не её фанат. Для того чтобы определить, при помощи какого варианта можно решать задачи быстрее, надо взять и посчитать. Посчитать надо нажатия клавиш, количество позиционирований курсора, кликов, двойных кликов, время, которое пользователь будет думать и время, которое будет думать сама система. Модель GOMS вам в помощь. Кстати, время решения задач при помощи интерфейса - единственный параметр, который вам получится посчитать.
3. Насколько система защищена от ошибок. Этот параметр делится на два подпараметра:

• Вероятность возникновения ошибки. Если в программе есть какое-то место, где пользователь может ошибиться, он обязательно ошибётся. Только в одних случаях – с большей вероятностью, в других – с меньшей. Так например, если вы сделаете кнопку два на два пиксела, то вероятность того, что пользователь промахнётся по ней гораздо выше, чем если бы кнопка была бы 20 на 20. Также вероятность того, что пользователь промахнётся мимо кнопки (конечно же нормальных размеров, эдак 50 на 20 пикселов) гораздо ниже, чем вероятность того, что он опечатается, набирая команду в командной строке. Очень хороший способ увеличить вероятность ошибки – это заставить пользователя помнить какие-нибудь вещи. А самый популярный способ перегрузить человеческую память – наплодить режимы. Сколько раз вы забывали переключать раскладку клавиатуры? :)
• Последствия ошибки. Если вы промахнётесь мимо кнопки и попадёте на пустое место, это гораздо менее страшно, чем если вы случайно попадёте по кнопке удаления документа, который вы составляли неделю. Особо досадно будет, когда отменить это удаление будет невозможно. Основной способ, при помощи которого можно улучшить данный параметр – сделать в программе undo/redo. Правда, не для каждой операции такой undo/redo можно сделать. Так например, когда уже отформатирован жесткий диск или взорвался реактор ядерной станции, которой вы управляете, сделать undo уже затруднительно. В этих случаях надо всеми возможными способами уменьшать вероятность возникновения ошибки (см. пункт 3.1).

1. Насколько программа управляема. Программа должна быть управляемой, подконтрольной, полностью слушаться пользователя и делать только очевидные вещи. Кнопки должны нажиматься, галочки включаться и отключаться, программа должна делать минимум неподконтрольных пользователю вещей. В плохо переведённой на русский язык прграммы «Excel 2007» в контекстном меню можно было встретить два пункта под названием «Вставить». Один из них вставлял новую строку, другой – содержимое буфера обмена. Если я печатаю текстовый документ, смотря на клавиатуру (метод слепой печати я так и не освоил), то радостное окошко программы «Download Master», оповещающее о том, что докачался файлик, не должно вероломно отбирать у меня клавиатурный фокус посреди недопечатанного слова. Если я поставил перенести десяток-другой гигабайт файлов с диска на диск и пошёл на обед, я хочу после обеда получить файлы, перенесённые с одного диска на другой. А не сообщение о том, какой-то файлик внезапно оказался с атрибутом «только на чтение», и вопрос, а действительно ли я хочу перенести этот файлик и подождать ещё полчасика?
2. И наконец, эстетическая сторона. Проще говоря, чтоб всё красиво было. Влад Головач в своей книге «Как мыть слона» называет этот параметр сексуальностью интерфейса. Этот параметр я специально сделал самым последним. Он ни в коем случай не должен препятствовать первым четырём, и никогда не должен быть единственным рассматриваемым. Иначе у вас получится красивая позолоченная какашка.

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

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

Конечно, в этой маленькой статейке невозможно рассказать об интерфейсах всё. Поэтому, читайте книжки, думайте головой, следуйте здравому смыслу и не ссорьтесь :)

Сколько лет уже прошло с тех времён, когда появился первый пользовательский интерфейс, а делать интерфейсы качественно научились очень немногие программисты. Мне доводилось пользоваться банкоматами где-то пяти разных банков, и в каждом из них я видел такие вещи, на которые без слёз и мата невозможно смотреть. Почему после того, как я положил деньги на счёт, банкомат говорит мне «Отмена» вместо «Вернуть карточку»? Почему когда я снимаю 1100 рублей, а в банкомате закончились сторублёвые купюры, он выплёвывает карточку и говорит «Транзакция завершилась неудачей. Код ошибки 508.»? Почему он не объяснил мне причину неудачи на человеческом языке? Почему сбербанковский банкомат при малейшем сбое программы (а сбоит она часто), забирает карточку и заставляет меня на следующий день в рабочее время переться в отделение с паспортом?

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

Почему-то до сих пор я встречаю комбобоксы, при разворачивании которых появляются три строчки и скролл, передвижение которого на один пиксел пролистывает два десятка элементов? Почему я так часто встречаю ужасные формулировки на псевдочеловеском языке и прочие вещи, исправить которые технически несложно? Ведь для этого программисту надо всего лишь поставить себя на место того человека, который будет этим пользоваться, а не на место программы. Почему для того, чтобы добраться до необходимой мне функциональности, я вынужден разгребать леса вложенных друг в друга меню с командами, которые мне, как и 99 процентам пользователей нафиг не нужны? Почему когда я перемещаю файлы с диска на диск и иду на обед, по возвращении вижу окошко о том, что какой-то файлик внезапно оказался с атрибутом «Только для чтения» и вопрос «А действительно ли я хочу то, что попросил систему сделать час назад»? Ведь все эти вещи описаны и разложены по полочкам в каждом первом учебнике по проектированию пользовательских интерфейсов!

Ладно, если убогий интерфейс будет причиной того, что я еще полчасика подожду, пока файлы скопируются. А ведь были случай, когда интерфейс, который наваял рукожопый проектировщик, стоил жизни людей. Например, львиная доля падежа самолётов – это незащищённый от ошибок интерфейс рабочего места диспетчера или пилота. То кнопка выключения автопилота окажется рядышком с подставкой для ноги, то система предложит маршрут, лежащий прямиком через ближайшую скалу. Причина этих аварий – плохой интерфейс, а официальная отмазка – человеческий фактор. Да что далеко ходить? Авария на Чернобыльской АЭС – ярчайший пример незащищённости интерфейса от шаловливых и часто ошибающихся ручек оператора, а «Официальная причина», как и обычно в таких случаях - человеческий фактор. Правда, если верить министру атомной энергетики, сейчас пульты управления атомных станций защищены от некорректных действий оператора прям до зубов. Хорошо, если так.

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

На самом деле, книжек по проектированию пользовательского интерфейса написано очень много. Я бы посоветовал начать с книги Влада Головача «Дизайн пользовательского интерфейса»

В этой книге автор вкратце рассказывает о том, что такое хороший интерфейс и даёт кучу рецептов, как сделать так, чтобы вашей программой можно было пользоваться. Книга очень практичная и конкретная, за что я её очень люблю. Она очень распространена в сети, и скачать её можно много откуда. Например, отсюда: http://rutracker.org/forum/viewtopic.php?t=263562 Только не спутайте с другой книжкой автора, которая называется «Дизайн пользовательского интерфейса. Искусство мыть слона». Хотя, та тоже ничего.

Ещё можно почитать книгу Алана Купера «Об интерфейсе»

Признаюсь честно, эту книгу я не читал, но её рекомендуют очень многие, в том числе и Влад Головач. Книжка эта стоит у меня в очереди на прочтение. Как прочитаю – обязательно поделюсь впечатлениями.
Заказать книжку можно здесь: http://www.ozon.ru/context/detail/id/4562908/

Ещё есть очень красочная, весёлая и увлекательная книжка Стива Круга «Не заставляйте меня думать».

Книжка посвящена, в основном, веб-сайтам, но несмотря на это, в ней есть очень много мыслей, которые будут полезны и разработчиков desktop-приложений. Основная мысль книги – то, что никто не читает мануалы к программам, а мануала к сайту в принципе быть не может. Открыв сайт, человек моментально должен понять, как с этим работать. Как сделать легко читаемый интерфейс – как раз и рассказывает эта замечательная книга.
Заказать книжку можно здесь: http://www.ozon.ru/context/detail/id/3795618/

Ещё можно почитать статейки Джоэла Спольски. Они очень невелики по объёму и находятся вот здесь: http://russian.joelonsoftware.com/uibook/chapters/1.html

Да. И если вы до сих пор не поняли, что ужасные интерфейсы – это действительно серьёзная проблема нашей постиндустриальной эпохи, почитайте книгу Алана Купера «Психбольница в руках пациента».

В этой книге автор объяснит вам, что всё плохо, что в области юзабилити – поле не паханое, а также расскажет, почему так всё происходит.
Предупреждение! В первой половине книги автор долго талдычит одно и потому же. Поэтому первую половину лучше читать по диагонали. Но зато вторая половина намного более содержательна, и читать её можно полностью. Также автор говорит обидные вещи в адрес программистов. Как пишут пишут на lurkmore<ссылка>, если вы начнёте ощущать боль в нижней части спины, следует смириться с фактом, что вы хомо логикус :) И ещё эта книжка не даёт практически никаких конкретных рецептов, разве что разбирает несколько интересных примеров. Но зато хорошо описывает процесс в общих чертах и более-менее вправляет мозги в нужную сторону.

Заказать книжку можно здесь: http://www.ozon.ru/context/detail/id/4710758/

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

А ты читаешь Джоэла Спольски?

Если не читаешь – бегом читать! Такие короткие, но очень содержательные и полезные статьи о программировании и всём, что с ним связано без воды и ваты – явление в сети очень редко.
Почитать эти статьи можно
здесь: http://local.joelonsoftware.com/mediawiki/index.php/Russian
еще вот здесь: http://russian.joelonsoftware.com/index.html
и ещё вот здесь, но на английском: http://www.joelonsoftware.com/
и ещё он из своих статей книжки сделал:
http://www.ozon.ru/context/detail/id/2820575/
http://www.ozon.ru/context/detail/id/4878099/

Несмотря на то, что считаю статьи Джоэла великолепными и более чем достойными прочтения, не согласен с ним по некоторым вопросам, а именно:
- Не считаю стремление довести программу до идеала хорошим для программиста качеством. Более того, считаю перфекционизм детской болезнью.
- Не считаю, что рассадить программистов по отдельным кабинетом - самый лучший вариант.
- Не считаю, что писать подробные спецификации нужно всегда и везде.
- Не считаю Excel одной из лучших когда-либо созданных программ.
- Не считаю .Net и Java-программистов недопрограммистами.
- Совсем не обожаю C++. Более того, программируя на C#, разочаровываюсь в плюсах с каждым годом всё больше.
А так, во многом согласен с автором.

Закодировался

Придумал новое значение слову "Закодировался" - очень долго программировал.

Несерьёзные доклады на серьёзные темы

Пересмотрел кучу видео Максима Дорофеева – одного из менеджеров лаборатории Касперского и офигенного докладчика на тему управления проектами и тестирования программ. В работах автора больше привлекает не то, о чём рассказывается, а КАК рассказывает автор. Рассказывает он понятно, интересно, а главное, невероятно позитивно. Предлагаю вашему вниманию особо понравившуюся мне работу – доклад об автоматизации тестирования «Обезъянки против роботов». Когда смотрел – валялся под столом.

TestLabs Part II

View more webinars from Maxim Dorofeev

Test Labs09 Dorofeev M Part III

View more webinars from Maxim Dorofeev

P.S. Когда писал, понял, что манера изложения чем-то напоминает растаманские сказки Дмитрия Гайдука :) 

Если повернуть монитор на 90 градусов

Уже три месяца, как работаю на мониторе, повёрнутом на 90 градусов.

(пропорции обозначенных панелей меняются в зависимости от потребностей и настроения)

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

Для того, чтобы больше строк вмещалось на экран, некоторые программисты сворачивают панельку с аутпутом, списком ошибок, call stack-ом и значениями переменных (watch list). Далее, когда требуется посмотреть на что-либо из вышеперечисленного, щёлкают на свёрнутой панельке и ждут, когда всё это развернётся. В общем, лишние щелчки мыши и ожидания, когда же панелька красиво и плавненько выплывет. Мне не нравится. Кстати, никто не знает, как сделать так, чтобы панельки в Вижуал студии выплывали не плавно и тормозно, а резко и быстро?

Особо большой кайф от вертикального расположения монитора я получил, работая с WPF, когда надо смотреть одновременно на XAML-код и дизайнер формочки. Как я ни располагал эти панельки на горизонтально размещённом мониторе, ничего хорошего не получалось.

Конечно, кто-то скажет, что программисту надо два монитора. Особенно разработчику GUI. Но, к сожалению, в большинстве компаний два монитора до сих пор считаются роскошью :(

А как вы поворачиваете монитор (мониторы) и как размещаете на нём (них) панельки?

Как вы олаживаете пограмму?

Вы когда-нибудь задумывались о том, как ищете и исправляете ошибки? Пытались ли выявить какие-то алгоритмы в своих действиях?  Обычно, в литературе описывают два способа поиска причины ошибки:

1. Аналитический. Мы вспоминаем, как должен работать алгоритм, смотрим на то, что написали и видим несоответствие наших мыслей и написанного кода.

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

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

Так например, среди способов, применяемых мною для отладки, я могу выделить наиболее часто применяемый:
1. Ищем точку, где программа работает. Для этого можно: поставить точку остановки в том месте, где программа ещё не успела сглючить, упростить входные параметры, выкинуть часть кода, заменить часть программы более тупыми алгоритмами или заглушками, откатиться в программе контроля версий до той ревизии, где всё работало и т.д. В общем, определиться с координатой, по которой вы будете осуществлять поиск и найти точку на выбранной оси, где всё работает. Назовём эту точку «A».
2. Аналогичным способом ищем точку, где программа не работает. Назовём эту точку «B».
3. Берём точку где-нибудь посередине. Назовём эту точку «C». Проверяем, работает ли программа в точке C.
4. Если программа в точке C не работает, сужаем диапазон поиска до AC. Если работает – сужаем до CB. Переходим к пункту 3, но с новым, более узким диапазоном поиска. И так до тех пор, пока не мы не найдём ошибку аналитическим путём.

А какие способы поиска ошибок вы знаете и применяете на практике?

Фэн-шуй в программировании

Страдание хернёй на рабочем месте укрепляет слух, боковое зрение и бдительность в целом :)

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

Надо сказать, я ненавижу, когда кто-то стоит у меня за спиной и пялит мне в монитор без спроса. Программирование, как и всякий творческий процесс – дело интимное. Когда кто-то наблюдает за моей работой без моего разрешения, для меня это сравнимо с тем, что я справляю нужду в туалете, а кто-то за этим пристально наблюдает. Ощущение очень неприятное и жутко демотивирующее. Даже детальные отчёты о каждом часе потраченного рабочего времени для меня будут более гуманным способом контроля. Я ни в коем случае не говорю о том, что я никому не хочу показывать свой код. Напротив, я буду очень благодарен за любое ревью моих модулей и любую конструктивную критику того, что я написал. Также я не против продемонстрировать как можно что-нибудь делать или как что-нибудь работает. Пожалуйста! Но с одним условием – сначала спроси у меня разрешение.

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

Так вот. В этом посте я хотел бы поговорить о расположении мебели в офисе. Мне очень нравится сидеть спиной к стене, чтобы ни одна зараза не пялила мне в монитор без спроса. Сейчас я работаю за рабочим местом моей мечты. Я сижу спиной не просто к стене, а к углу. И стол развётнут к стене не под углом 45 градусов, а ровно под тем углом, который выбрал я сам, под которым мне наиболее комфортно работать. И, надо сказать, от этого я получаю огромный кайф, и очень благодарен за это и компании, в которой работаю и своему начальнику.

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

Тайм-менеджмент для иррационалов

К сожалению, сделать в сутках более 24-х часов мы не в состоянии. Но зато вполне в состоянии более экономно и осознанно расходовать подаренное нам жизнью время. О том, как это сделать, написано много разных книг по дисциплине, которая называется «Тайм-менеджмент». Многие из практик, предлагаемые этой дисциплиной действительно очень эффективны с одним «Но». Не всё, что описывается в тайм-менеджменте подходит абсолютно всем людям.

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

Так вот. Если вы рационал, то я хотел бы вам порекомендовать прочитать какую-нибудь по классическому тайм-менеджменту. Например, вот эту: http://www.ozon.ru/context/detail/id/5134485/

Если же вы иррационал, то я бы вам также порекомендовал ознакомиться с этой книжкой. Всё-таки, там есть некоторые полезные советы и для вас. А ещё я бы настоятельно порекомендовал ознакомиться с двумя небольшими, но невероятно полезными статьями Ивана Пирога «Тайм менеджмент для иррационалов»:
http://www.ivanpirog.com/posts/spontannoe-planirovanie-dlya-tex-kto-nenavidit-tajm-menedzhment/
http://www.ivanpirog.com/posts/formula-uspexa-spontannoe-planirovanie-i-zhizn-v-potoke/
 Я надеюсь, что прочитав её вы узнаете многое о себе, о своей природе и о способах, как наиболее эффективно использовать своё время.

Также обоим лагерям предлагаю ознакомиться ещё и с вот этой замечательной статейкой: http://rsdn.ru/article/career/doitnow.xml

Удачи в изучении. И не ссорьтесь :)

Человеческий фактор в управлении проектами

К сожалению, до сих пор бытует мнение, что управлять проектом и построить диаграмму Ганта – это одно и то же. Так например, я неоднократно натыкался на курсы, под названием «Управление проектами», содержанием которых было – как пользоваться «Microsoft Project», и всё! В большинстве требований к вакансиям «Менеджер проекта» - «Владение Microsoft Project в совершенстве», но ни слова об умении общаться, разрешать конфликты, да и просто организовывать что-нибудь! Вы можете со мной спорить, но моё мнение – управление проектами – это не диаграмма Ганта, а люди, люди и ещё раз люди. Плюс немного специфики разработки программ, которую также надо знать.

Возникает вопрос. А как же управлять не набором случайных чисел, выданных программистами в виде оценки срока выполнения задач и упакованных в диаграмму Ганта, а управлять ЛЮДЬМИ? Ответы на эти вопросы вы можете найти в по-настоящему уникальной книге Сергея Архипенкова «Руководство командой разработчиков программного обеспечения. Прикладные мысли».

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

Скачать книгу вы можете с официального сайта автора: http://www.arkhipenkov.ru/resources/sw_team_management.pdf

Не мешайте мне работать

Хороший программист работает в десятки раз продуктивнее плохого. Но! Производительность одного и того же программиста может отличаться также в десятки раз. Какова же причина того, насколько человек работает хорошо или плохо? Один из основных ответов – мотивация. Чем можно мотивировать человека, чтобы он работал максимально продуктивно и с огоньком в глазах? Многие при ответе на этот вопрос ссылаются на пирамиду Маслоу – сначала человек хочет кушать, потом чувствовать себя в безопасности, потом хочет, чтобы его уважали и любили и т.д. Но всё это довольно общая теория без учёта специфики именно программистов. Программисты – это большей части люди увлекающиеся, и иногда достаточно их просто не демотивировать. Мне было интересно получить чёткие мысли для ответа на вопрос: «Как замотивировать программиста, чтобы он работал продуктивно?». И, пожалуй, ответ на этот вопрос я получил в книге Стаса Давыдова «Не мешайте мне работать». В этой небольшой, но очень ёмкой книге автор даёт очень чёткие инструкции, как сделать так, чтобы человек работал с огоньком в глазах, ходил на работу как на праздник и пахал на полную катушку.

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

Скачать книгу можно с сайта автора здесь: http://motivateme.ru/motivate-me-right-1.3.pdf

P.S. Если эту статью читает моё начальство, то хочу сказать, что на моей теперешней работе я замотивирован как никогда раньше. Я занимаюсь любимым делом в комфортных для меня условиях, и мне за это даже платят деньги. И самое главное, не мешают работать :) За что я очень благодарен.

Читать книги с текстовыделителем

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

Надо чаще ходить на конференции

Я Ленина Александра Орлова видел! Живого!

На прошлой неделе посетил конференцию, организованную сообществами happy-pm.com и  stratoplan.ru
Впечатление от мероприятия осталось очень хорошим. Прозвучало много интересных мыслей, и было озвучено много интересного жизненного опыта. Особенно понравился доклад Романа Юрьева «10 заповедей для родителей программиста» Видео этого замечательного доклада, но правда с другой конференции, можно посмотреть здесь.

happy-pm.com

Который раз захожу сайт www.happy-pm.com – кладезь прикладных мыслей и жизненного опыта в управлении программными проектами. Особенно интересно смотреть на свой управленческий опыт через призму этих статей и видеороликов. Сколько ж я ошибок-то наделал! Стандартных и хорошо описанных в литературе. С другой стороны, мои ошибки – это мой опыт, который, я надеюсь, не даст совершить их вновь.

Чем я вдохновлялся записывая видео "Как программировать эффективно и качественно"

Большое спасибо всем, кто уделил внимание моей работе «Как программировать эффективно и качественно». Хочу добавить, что большинство мыслей, прозвучавшие в этом видео – совсем не моё изобретение. Моя задача – собрать наиболее важные мысли на эту тему и в течение часа их максимально сжато озвучить. Прежде чем приступить к записи, я прочитал множество книг. От всяческих «Эффективное использование <название какого-нибудь языка>» и до верёвок, выстреливающих в ногу. Из всего прочитанного, особенно хотелось бы отметить книгу Стива Макконнела «Совершенный код».

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

Заказать книжку можно здесь: http://www.ozon.ru/context/detail/id/5508646/

Это должен знать каждый инженер

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

Кстати, книжка стоит очень недорого и заказать её можно здесь: http://www.ozon.ru/context/detail/id/4939485/

Библия системного архитектора

Спешу сообщить вам. Вышло третье издание книги Гради Буча «Объектно-ориентированный анализ и проектирование с примерами приложений» на русском языке! Книги, которую я считаю библией системного архитектора. Не смотря на то, что первое издание этой книги было написано ещё в восемьдесят лохматом году, темы, которые поднимаются в ней, остаются актуальными до сих пор. Также как до сих пор остаётся актуальным объектно-ориентированное программирование.

Главная ценность этой книги заключается в том, что она, в первую очередь, учит мыслить так, как должен мыслить человек, проектирующий программу на объектно-ориентированном языке. Для любой группы объектов можно придумать бесконечное количество классификаций. Любую задачу можно решить бесконечным количеством способов. Ваша цель – выбрать наиболее оптимальный способ. Ответ на вопрос «Как это сделать?», возможно, вы найдёте в этой замечательной книге.

Заказать книжку можно здесь: http://www.ozon.ru/context/detail/id/3905587/?isbn=978-5-8459-1401-9

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

Здравствуйте. Меня зовут Михаил Песков. Хочу предоставить вашему вниманию первое снятое мной видеопособие. Чтобы вам было понятнее, о чём это видео, и этот журнал, давайте я расскажу немного о себе.

Я программист. Программирую я уже порядка 15-ти лет, из них 9 лет – профессионально. В течение 5-ти лет мне доводилось читать некоторые курсы, связанные с программированием в одном из университетов нашей страны. На одном из последних мест моей работы, я в течение трёх с половиной лет возглавлял небольшой коллектив программистов порядка семи человек. За время моей профессиональной деятельности через меня прошли десятки начинающих программистов, которым мне доводилось ставить технику написания и отладки программ. Сейчас я преподавательской деятельностью не занимаюсь, но очень хочу, чтобы мой опыт сохранился и передался следующим поколениям. С этой целью я решил записать несколько видео, первое из которых я хочу предоставить вам.

За время своей работы мне очень часто приходилось работать с начинающими программистами. В одно время я стал замечать, что оказывается, большинство новичков совершают одни и те же ошибки. Чтобы облегчить свой труд, я написал небольшую брошюрку, в которой перечислил ряд рекомендаций, которые могли бы помочь человеку сделать свои первые шаги в этой замечательной профессии без похода по граблям, набившим лоб уже не одному предыдущему поколению. В этих рекомендациях было написано, как лучше писать программу и к чему следует стремиться. А самое главное – исходя из каких причин это нужно делать. Результат не заставил себя долго ждать, и мои подопечные довольно-таки быстро поднялись в своём профессиональном уровне. В течение двух лет я обкатывал этот материал, старался его сделать лаконичнее, но в то же время, не упустить что-нибудь важное. И вот теперь я хочу представить результат моего труда в этом видео.

Данное видео предназначено в основном для начинающих программистов. В нём я старался рассказать о тех вещах, которые обычно не даются в наших ВУЗах, но тем не менее, очень важны в работе каждого программиста. Возможно, материал этого видео будет полезен и не новичкам. По крайней мере, я надеюсь, что опытные разработчики, просмотревшие данный видеокурс, смогут систематизировать свои знания и лучше понять причины, по которым следует или не следует делать какие-либо вещи. Я очень надеюсь, что это видео поможет вам повысить качество и эффективность своей работы. В общем, желаю вам приятного просмотра.