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

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

Две профессиональные цели я тогда для себя определил — снова поучаствовать в профессиональном обучающем мероприятии (до этого я один раз участвовал на 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 апреля и группа уже почти собрана.
Ну и  упомянутую книжку почитать будет не бесполезно, в ней есть над чем задуматься.

Стратосфера в Таганроге

Кто-то уже знаком немного с форматом Стратосферы, кто-то нет, расскажу кратко:

• Полноценное обучение не покидая Таганрога.
• Большой объём практики (примерно 60%) со специально разработанными заданиями, с провокациями, с групповой работой.
• Вы можете выполнять задания с малознакомыми людьми, что повышает качество обратной связи, позволяет выявить неэффективные шаблоны поведения и даёт больше нового опыта.
• Полное погружение – семинар/тренинг длится 6 часов.
• Эффект присутствия – трансляция на большой экран в хорошем качестве, картинка докладчика с флипчартом и картинка со слайдом.
• Каждый участник получает рабочую тетрадь, сертификат, материалы в электронном виде.
• Стоит в примерно 4-6 раз дешевле, чем если бы Вы ехали на подобный тренинг в Ростов, Краснодар или Москву. Для сравнения, AgileDays на два дня 26500руб, плюс дорога, плюс проживание.

Подробнее можно ознакомиться тут.

Что я предлагаю

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

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

Что нужно сделать вам

1. Выбрать интересующие семинары из списка.
2. Зарегистрироваться по приведённой в списке ссылке. Точка принятия решения – примерно за неделю до семинара.
3. Ждать. Если набирается группа – я рассылаю всем подтверждение и информацию куда приходить и приносить деньги. Ориентир по сумме оплаты – от $100 до $50 (можете при желании пересчитать сами на основе цен организаторов).
4. Приходите, платите мне аванс для перечисления организаторам.
5. Я оплачиваю аванс, готовлюсь к семинару (готовлю рабочие тетради, материалы к практическим занятиям, тестирую оборудование).
6. В день семинара вы приходите, занимаетесь, получаете сертификат. Возможно, верну какую-то сумму, если придёт больше людей, чем планировалось.
7. Применяете полученные знания и навыки на практике :)

Почему предлагаю работать со мной

1. Уверен, что у меня всё получится так, как нужно. Имею большой опыт организации разного рода совместных мероприятий. В феврале организовывал конференцию такого же формата, которую посетили 70 человек. Друзья помогли, всё получилось вполне неплохо, много положительных отзывов.
2. Не кину по деньгам, всё проведу в лучшем виде. Кто меня не знает – пообщайтесь с моими друзьями из вконтакта. Они расскажут, как я работаю, скрывать нечего ;)
3. Буду участвовать в групповой работе, поделюсь опытом.

Если всё устраивает – список ближайших семинаров.

Как найти деньги

Вариантов масса, основных как минимум два.

Самый простой – сэкономить на одном-двух походах в ресторан/кафе, инвестировать в себя, повысить свою эффективность и убедить руководство поднять оклад. Вернуть инвестицию в течение 1-2 месяцев.

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

Остальное зависит от вашей фантазии, воли и предприимчивости :)

Если всё устраивает – список ближайших семинаров.

Зачем мне это надо

Как вы заметили, моей финансовой выгоды тут нет.

Причин заниматься этим у меня несколько, озвучу наиболее чёткие.

• Имею возможность.
• Прохожу все семинары "бесплатно" – я за себя плачу своим трудом.
• Считаю, что если сам не организую семинар, то не смогу его провести даже если буду готов заплатить деньги. В Таганроге был только один открытый тренинг Стратосферы, на нём было два участника – я и моя жена.
• Когда был помоложе был бы очень рад возможности учиться на таких условиях, но приходилось ездить в Ростов и платить от 20 тыс рублей (цены 2003-2005 годов).
• Мне не всё равно и мне нравится общаться с людьми, которым тоже не всё равно.

Тем не менее, любая добровольная помощь приветствуется. Родина не забудет ;) Самый простой вклад – сделать репост и порекомендовать знакомым.

И ещё раз список ближайших семинаров.

О силе социальных связей

Есть такая управленческая дисциплина — Human Resource Management (в переводе "Управление человеческими ресурсами" или "Управление персоналом"), в ней задолго до фейсбука был термин "социальная сеть", который обозначал связи, которыми "обрастает" сотрудник за время работы на предприятии. Эта дисциплина работала с такого рода связями потому, что они повышали ценность сотрудника для организации. От отношений сотрудника с коллегами и от знания специфики их работы зависит эффективность данного сотрудника и его шансы на карьерный рост.

Расскажу как это работает на примере организации Стратоплан Гранд Конференс в Таганроге.

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

Тем не менее, как только был опубликован анонс, начали происходить чудеса:

1. Несколько человек сразу спросили, не нужна ли помощь в организации.
2. Алексей Кошкидько договорился с университетом о предоставлении помещения на 90 человек, взяв на себя весь связанный с этим головняк.
3. Валерий Хашковский организовал интернет на 30 МБит с резервным каналом, помог в тестовых сессиях, держал наготове дублирующий проектор и предоставил чайник, которым мы потом поили всю банду ;)
4. Виталий Попов оказал неоценимую помощь в настройке оборудования в зале.
5. Дмитрий Папуша помог в организации, закупке и доставке разной мелочевки и обеспечил всех водой.
6. Антон Краснов притянул личный термос, а также с двумя замечательными женщинами, пожелавшими остаться неизвестными, взяли на себя ответственность и воспользовавшись служебным положением выделили нам ещё два термоса, в которых готовили кофе :)
7. Василий Хатунцев нашёл нам девайс для нарезки "нарезки" на бутеры (такой вот каламбур ;)
8. Андрей Курило и Артём Кобилинский вызвались помочь расставить столы-стулья утром 16-го и убирать вечером 17-го.
9. Множество людей сделало репосты, обеспечив 870 просмотров моего приглашения.

Вот этот порыв взаимопомощи наглядно демонстрирует силу социальной сети, которая включается в момент преодоления трудностей и помогает их преодолеть. Когда всё хорошо и проблем нет — любой справится с задачей. Поэтому дисциплина управления персоналом занимается, помимо всего прочего, развитием социальной сети сотрудника, а современные системы совместной работы обзаводятся элементами социальных сетей (в частности, Sharepoint).

В двух словах, как можно развить свою сеть:

1. Общайтесь с коллегами. Как ни странно, но в коллективах больше 5-10 человек находятся люди, которые не знают, чем занимаются их коллеги. Общайтесь больше, интересуйтесь, чем занимается "сосед по парте". Помогайте соседу.
2. Рекомендую не пропускать корпоративы, если вы работаете в достаточно больших коллективах и стараться участвовать в разной непроизводственной деятельности. Неформальные контакты гораздо сильнее работают, чем формальные.
3. Участвуйте в разного рода сообществах и посещайте мероприятий, такие как Таганрогское сообщество разработчиков и семинары Стратоплана или даже выездные, вроде DevCon и AgileDays. И обязательно на них знакомьтесь с интересными людьми.
4. Развивайтесь профессионально и не портите личные отношения без необходимости ;)
5. Включайте в круг общения как коллег, так и начальство и перспективную молодежь.
6. Делайте правильные упражнения.

Успехов!

P.S. 

Пользуясь случаем, хочу отдельно поблагодарить:

1. Свою жену за помощь и поддержку как на самом мероприятии, так и вообще по жизни ;)
2. Наших детей за то, что несмотря ни на что любят своих сумасшедших родителей.
3. Нашу сотрудницу Марину за помощь на конференции в свой законных выходной.
4. Сашу с Леной за бульбулятор, зефирки и кофе.
5. Всех, кто пришёл на конференцию и активно работал с нами вместе.

Общение с клиентом: влияние

Это вторая часть цикла под общим названием «Как общаться с заказчиком». В этой части рассмотрю, как оказывать влияние на клиента и доводить до него свою позицию.

Описание ситуации, которую я разбираю и как эффективно получать информацию от клиента читайте в первой части.

Скажу сразу – влиять на клиента сложно, потому что простое манипулирование он сразу распознает и отреагирует. В конце концов, если он Вас нанял, а не наоборот, значит, скорее всего, навыками общения и достижения целей он не обделён ;)

Тем не менее, есть кое-какие приемы, которые могут позволить Вам проявить себя и переубедить клиента, если он не прав. Осторожно, психологический хардкор! :)

1. Ни в коем случае у клиента не должно создаваться впечатление, что вы просто не хотите что-то делать или наоборот, хотите сделать больше, чем хочет клиент (за его счет, конечно). Почитайте «Оптимальное vs правильное» и будьте готовы обосновать свою позицию.
2. Предложение должно быть выражено в терминах бизнеса, а не технических. «Вам в команду нужен тестировщик? Чтобы он искал ошибки? Вы же профессионалы, тестируйте свой код перед заливкой!» ;) пример правильной формулировки (убеждая, что тестировщик должен работать постоянно, а не набегами) – «если тестировать задачу сразу после заливки, а не в конце спринта, то у нас в течение спринта будет более актуальная информация о прогрессе, а устранение ошибок будет занимать меньше времени, так как программисту не нужно будет вспоминать детали реализации, кроме того, если вы захотите посмотреть сайт в середине спринта, он будет работать стабильнее».
3. Думайте о том, чьи интересы будут затронуты решением. Если специалист заказчика выбрал компоненты стоимостью в самолет, то чтобы убедить клиента от них отказаться придется что-то делать с авторитетом этого специалиста, ведь он будет отвечать за расход денег. Клиент не силен в технической части, поэтому частично решение принимается на эмоциях – на том, как упомянутый специалист будет отзываться о вас (а он найдет к чему придраться). Рекомендация – общаться напрямую с тем, кто принял решение, и дать ему аргументы, с которыми он сам сможет пойти к Вашему клиенту и объяснить, в чем была ошибка, как извлечь из ситуации пользу. Так он сохранит свое лицо, вы же заработаете союзника.
4. Люди не любят, когда их припирают к стенке. Это выглядит как шантаж, или проблема, а проблемы никто не любит. Правильная стратегия – предоставить возможность выбора. Как минимум два варианта. В памяти отложится то, как вы конструктивно относитесь к проекту.
5. Типовая ситуация – от клиента требуется принять решение, но он тянет. Ждать клиента – плохой выбор, потому что если промедление создаст проблему, виноват будет ПМ – он не смог вовремя всё предусмотреть. Поэтому вопросы нужно задавать заранее, четко проговаривать, к какому моменту решение должно быть принято, озвучить последствия затягивания решения. Как крайняя мера – предложить план Б, предложить временное решение пока нет решения окончательного. Поскольку нет ничего более постоянного, чем временное, данное предложение должно быть очень взвешенным ;)
6. Если клиент в принципе тянульщик – сделайте быстрый прототип. Увидев и пощупав результат, клиенту будет проще сделать выбор. Как совсем экстремальный вариант можно попробовать принять решение самостоятельно, сообщить, что Вы сделали так-то и так-то, объяснить причину и предложить пообщаться, если клиенту вариант не нравится. Тут есть риск, но можно выиграть в доверии. Этот путь требует осторожности – если клиента уже попросили принять решение, то нужно ждать его решения, иначе потеряете лицо.
7. Будьте последовательны. Клиент помнит все Ваши проколы, а если Вы начинаете метаться, это уже подозрение на непрофессионализм. Отстаивайте свое мнение, если клиент напирает – делайте, как он хочет, но оставьте за собой право на альтернативное мнение. Иначе у клиента в памяти отложится, что вы с ним согласились, а после этого нельзя уже будет сказать «вот, а я предупреждал». 
8. Копите аргументы. Многие решения принимаются эмоционально, в момент осознания проблемы не только головой, но и сердцем. В этот момент ваша аргументация может сработать эффективнее. Сделайте в почтовом клиенте специальную папку и складывайте в неё факты. Если их выдать клиенту в правильный момент, когда его сознание находится в контексте ситуации, Вы произведете впечатление ясностью и аргументированностью своей позиции (и никакой игры на эмоциях ;)
9. Более общее описание предыдущего пункта – большую часть времени люди проводят в трансе, принимая типовые решения в ответ на типовые ситуации. Нетиповая ситуация выводит человека в стрессовое состояние – состояние мобилизации всех сил организма, в частности, мыслительных способностей. Именно в этом состоянии человек более склонен принять решение что-то изменить. Стрессового состояния можно дожидаться (ждать, пока не возникнет какая-то проблема), либо создавать (например, обрисовывая возможные последствия). Тонкий момент со стрессом состоит в том, что если перегнуть планку, включается защитная система организма – шок. В этом случае мозг перестает воспринимать информацию и клиент говорит «извините ребята, вы меня расстроили, я не знаю что делать, давайте общаться завтра». С другой стороны, если ваши аргументы будут всегда одни и те же, то у клиента выработается автоматическая реакция на этот аргумент, и он перестанет воспринимать такой аргумент вообще. Поэтому не желательно описывать проблему два раза одними и теми же словами.
10. Есть один более-менее универсальный способ вывести человека из состояния транса. Особенно хорошо это работает с западным человеком. Нужно предложить ему провести разбор полетов и определить, как не допускать подобных проблем в будущем. Английский термин – «Lessons learned». Это будет очень конструктивно и очень своевременно.

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

На этом пока всё, успехов!

Стратоплан Гранд Конференс в Таганроге

Коллеги, я большой фанат ребят из Стратоплана и хочу вас пригласить на уникальное событие, которое будет происходить у нас в Таганроге – на бесплатную конференцию "Стратоплан Гранд Конференс", которая состоится 16-17 февраля 2013 года и будет посвящена работе с людьми!

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

Сам я посетил несколько их курсов и считаю данный формат уникальным – это образование высокого профессионального уровня, без командировок и с минимумом затрат. А в случае "Стратоплан Гранд Конференс" – вообще бесплатно. А самое главное – это большой объем практики, что невозможно получить чтением книжек и слишком дорого нарабатывать самостоятельно.

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

UPD: я думаю, 90 человек – максимум, который сможет более-менее комфортно работать в группе в том помещении, которое у нас есть.
UPD2: Сегодня вечером организаторы закрывают регистрацию, чтобы подготовить все материалы. Поскольку у нас уже 90 человек, я закрываю регистрацию прямо сейчас.

Если вы ещё думаете, перечислю преимущества, которые я вижу:

1. Для менеджеров проектов и тимлидов – это вообще на 100% ваша тема. Анализ резюме, переговоры (в широком смысле слова), мотивация, проектное управление, личная эффективность. Только подумайте о том, какой опыт вы получите в результате работы в группах с коллегами из других фирм/сфер! 
2. Для разработчиков, тестеров и вообще инженеров-профессионалов – если вы не намерены стоять на месте, если интересуетесь личным и профессиональным развитием: 
1. как правильно общаться с руководством, коллегами, заказчиком; 
2. как решить проблемы в проекте, если что-то в нём не так; 
3. понять, что вас мотивирует, сфокусироваться на этом и составить план достижения цели; 
4. дать себе "волшебного пендаля" и двигаться вперёд, если желание есть, а с движением туго; 
5. в конце концов, как написать резюме, чтобы оно "стрельнуло" и правильно общаться с потенциальным работодателем! 
3. Для фрилансеров – тоже на 100% ваша тема. Мне самому знакомо, как сложно получать новый опыт работая самому на себя. Тем не менее, эффективно общаться, решать проблемы, повышать свою эффективность, планировать свою работу и развитие важно как никому другому. 
4. Для руководителей и ответственных за развитие персонала. Отправьте своих сотрудников на конференцию – зарядите их новым опытом, позитивом и идеями. В первую очередь ваш кадровый резерв – дайте им понять, что вы готовы к их росту и развитию. Попросите их подумать, кого и на какие дальнейшие семинары стоит отправить. Эти семинары тоже будут в Таганроге. 
5. Для студентов – такого вам ни в Радике, ни где-то ещё не дадут. Правильное понимание себя, своих целей, эффективное развитие своей карьеры сэкономит вам несколько лет жизни. 
6. Для всех – насыщенная программа, авторитетные докладчики, большой объем практики – в том числе из других фирм/сфер. 
7. Для тех, кто меня знает – я взялся организовывать данное мероприятие в Таганроге. Потому что считаю это правильным. Считайте это доказательством моей оценки формата обучения вообще и мероприятия в частности.

UPD: я думаю, 90 человек – максимум, который сможет более-менее комфортно работать в группе в том помещении, которое у нас есть.
UPD2: Сегодня вечером организаторы закрывают регистрацию, чтобы подготовить все материалы. Поскольку у нас уже 90 человек, я закрываю регистрацию прямо сейчас.

UPD: Место проведения – пер. Некрасовский, 44. Корпус "Д" ТТИ/ТРТУ, аудитория Д-229 (зал ученого совета). Программа конференции.

Общение с клиентом: получение информации

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

Для начала дислокация сил. Опишу ситуацию, для которой буду делать разбор.

Итак, вы – руководитель проекта или лидер группы разработчиков, нашли себе (или директор/сейлз Вам выдал) клиента.

Клиент.

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

Ожидания клиента в рамках взаимодействия с Вами:

• Получить на другой стороне «провода» профессионала, готового быстро понять заказчика и думать на перспективу.
• Реализация своих требований максимально эффективно (быстро и недорого).
• В идеале – получить «технологического партнера», который будет создавать, развивать и поддерживать продукт в соответствии с требованиями бизнеса.

ПМ.

• Начинающий менеджер/тимлид, или впервые сталкивающийся с «бизнес-клиентом» (для людей «с историей», наверняка, что-то будет уже привычно, но буду ориентироваться на общий случай).
• Понимает, что клиент мало что про него знает и относится с недоверием и предполагает (зачастую оправданно), что клиент будет его всячески контролировать и припоминать все проколы.
• Считает (скорее всего), что фактор цены для клиента важен, потому что рынок конкурентный и клиент легко может уйти к другому исполнителю.
• Ритм работы не совпадает с ритмом заказчика и, скорее всего, язык общения – не родной.

Цели ПМа:

• Оправдать доверие начальства/команды, за то, что именно он представляет команду перед заказчиком в проекте (да, бывает и по-другому, но этот случай я тут рассматривать тоже не буду).
• Произвести на клиента максимально положительное впечатление и, в идеале, пачку интересных и выгодных проектов.

Для начала техника безопасности («где находится невлезайубьёт»). Типовые ошибки, которые допускают стороны:

Клиент.
Ладно, бросьте, клиент может совершить только одну ошибку – выбрать не того исполнителя. Он платит Вам деньги за то, чтобы Вы делали свою работу, а также терпеливо отвечает на Ваши вопросы, определяет приоритеты и принимает работу (дает обратную связь). Всё остальное, что можно назвать «ошибкой» – либо Ваш косяк, либо осознанное принятие риска клиентом. Баста.

ПМ. Выделю три проблемы, к которым, думаю, можно свести большинство остальных:

1. Неуемное стремление сразу же понравиться заказчику. Сразу, на старте. Вариантов на этой стадии немного, а самый очевидный – занижать сроки. Результат – овертаймы, нередко сдвиг сроков и/или падение качества, нервозность с обеих сторон.
2. «Чукча умный», а умные ребята всё понимают с первого раза и умеют оценивать задачи слёту. Страх выглядеть глупым, имхо, закладывается ещё в детстве. Результат же данного прокола довольно очевиден – ПМ додумывает за заказчика и возникает информационный вакуум с обеих сторон, который заполняется домыслами.
3. Непонимание сущности своей роли в проекте, ролей клиента и разработчика, а также сопутствующих прав и обязанностей. Как следствие, неправильные ожидания, непонимание, конфликты интересов, недовольство процессом.

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

1. Клиент рассказал, чего он хочет, вроде всё понятно, но Вы ещё не научились понимать его с полуслова. Перескажите свою задачу своими словами и попросите подтвердить. «Правильно ли я понял, что необходимо реализовать…?» «Please correct me, if I’m wrong, we need to…» «OK, let me sum up, this function should…»
2. Клиент рассказал суть задачи, даже ответил на вопросы, но как-то ходит вокруг да около, мало конкретики. Можно попробовать зайти с другого конца – спросить не о требуемой логике, а о конечном результате, как задача будет тестироваться. «Как Вы будете принимать задачу?» «Please, tell me how I’ll be able to demo this task to you»
3. Хорошо бы ещё фильтровать случаи, когда заказчик пытается сам предложить Вам решение вместо постановки проблемы. В результате Вам придется всё переделать после того, как клиент увидит, что Вы ему сделали (да, формально Вашей вины нет и клиент подтвердит, но осадок останется). Тут поможет техника трех зачем.
4. Клиент спрашивает Вашу оценку сроков реализации задачи. По факту, он просто любопытствует, не выйдет ли он за границы бюджета, но если Вы назовете цифру, будьте уверены, что он её запомнит. Нервничать и казаться умнее не нужно, вполне нормально сказать, что вам нужно помедитировать над задачей, обсудить с разработчиками и т.п. для выдачи оценки. Если клиент настаивает, можно дать грубую оценку обязательно уточнив, что оцениваете – объем работ или срок сдачи и какие задачи нужно будет подвинуть, чтобы сделать её приоритетно. «Let me think about this task and email you with my estimates» «I’ll need to discuss it with developer(s)» «My very rough estimate is within a week, I can estimate it more precisely if needed» «I think, we can complete it tomorrow, if we postpone tasks …»
5. Вроде все детали понятны, но задача сложная, деталей много и клиент уж слишком часто и быстро отвечает «да» на Ваши вопросы, и есть ощущение, что он не вникает в суть вопросов. Тут хорошо бы немного взбодрить клиента – описывая, как Вы видите задачу выдать ему 100% не проходное предложение, на которое он должен сразу же отреагировать. «Вот тут пользователь сможет импортировать 10000 email’ов, после чего программа затребует у пользователя для каждого из email’ов них вручную ввести фамилию и имя в соответствующие поля» «We assume that imported list is already free from duplicates and does not contain duplicated of already existing data». Инструмент тонкий и требует политического такта, но может разговорить даже сложного клиента.
6. Экономьте время клиента – если нужно что-то уточнить, то вопрос должен формулироваться так, чтобы клиент затратил минимальное время на прочтение и осознание вопроса и собственно на ответ. Вопрос формулируйте кратко (особенно на иностранном языке, меньше слов – меньше ошибок). Готовьтесь к любой коммуникации и предлагайте варианты решения. Ну и если общаетесь на иностранном языке – чем меньше слов, тем меньше шансов ошибиться в грамматике или значении слова.
7. По возможности, а особенно для иностранцев – они думают глазами, нарисуйте диаграмму. Также не забывайте, что людям зачастую сложно воспринимать информацию на слух (см. корпоративные болезни), правильное использование этих особенностей повысит скорость коммуникации.
8. Узнайте, когда клиент приходит на работу, когда у него есть время для оперативного общения, когда не тревожить, в какие дни он не в офисе и вопросы решить нельзя. По возможности договоритесь о каких-то соглашениях как помечать срочные вопросы, о гарантированном времени для решения текущих вопросов (ежедневные митинги). Адаптируйтесь к рабочему графику клиента, готовьте ответы к моменту, когда у него начинается рабочий день, резервируйте время в своем графике на время его активности.
9. Не стесняйтесь предложить пообщаться вживую, если переписка стала слишком длинной.
10. После живого общения хорошо бы подбить итоги общения и отправить клиенту. «Let me recap results of our discussion. We agreed on…, I’ll do…, you’ve promised to do…» Для углубленного изучения рекомендую подборку материалов по совещаниям.
11. Напоминайте заказчику о наступающих событиях сами, в том числе о его обещаниях выдать информацию. Мало ли что, в конце концов это не его обязанность помнить обо всём. «Hi, just a kind reminder, I’m waiting for this information from you.»

В следующей части – как оказывать влияние на клиента и доводить до него свою позицию.