Невменяемость клиентов

Не так давно мне на глаза попалась статья Максима Молодцова (руководителя отдела дизайна компании РБК-Софт), в которой он довольно точно представил типологию клиентов с хорошим описанием всех типов, ниже я приведу эти типы. Что мне понравилось в этой статье, это с какой точностью автор собрал и описал все типы клиентов. respect. Я сразу же вспомнил всех своих клиентов и клиентов моих подчиненных и переложив их на эту типологию понял, какой титанический труд мы выполняем проектируя и создавая сайты.

И от себя я решил добавить небольшую историю, которая произошла буквально вчера с одним из моих ПМ'ов. Обсуждая на встрече с клиентом техническое задание на разработку сайта. ПМ получил от клиента такую реплику: "я ничего здесь не понимаю и для меня слово "иконка" обозначает "небольшое изображение Иисуса Христа", а слово "ссылка" я понимаю лишь в контексте декабристов и ссылки их в Сибирь, про слово "поле" я могу сказать, что это поле где растет рожь и пшеница, а также всякие цветочки. Карта сайта это быстро, а меню это долго. Счетчики посещаемости должны отслеживать кто зашел на сайт: мужчина или женщина, старик или ребенок. И вообще в IT-сфере работают безграмотные люди, которые неправильно используют русский язык".

После того, как я услышал это от ПМа я понял, что мы встряли...

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

"...Если вы общаетесь напрямую с телом — в любом случае это удача. Ваш путь к сдаче проекта должен быть короче и проще. Но. Бывают нюансы потому, что встречаются такие тела как:

1. Кретин — личность с непредсказуемыми реакциями. Он постоянно будет менять свое мнение, приоритеты, жонглировать целями и задачами. Хороший пример это ситуация «клиент не натанцевался» — то есть не получил удовлетворения в том объеме, в каком перечислил вам средства (объем он оценивает по своей внутренней шкале). И вот тут «кретин» будет продолжать процесс даже в том случае, если результат уже достигнут и всякое продолжение ведет только к его ухудшению.
2. Царь — личность снизошедшая до сотрудничества (общения) с вами. В каждый момент времени он будет укреплять в вас чувство, что вы тратите его бесценное время. Любое его слово надо ловить, каждый его взгляд хранить в своем сердце. Царь одноканален. Он работает только на вещание. Чаще всего все, что он вещает — чушь собачья. Но научитесь воспринимать ее серьезно.
3. Карабас-барабас — персонаж, желающий в вашем лице послушных кукол. Он будет манипулировать процессом, навязывать вам свои решения и требовать их неукоснительного исполнения. Все ваши доводы о нецелесообразности этих решений будут с негодованием отметаться (чем больше предложений, тем больше негодование).
4. Незнайка — человек, который через слово вставляет «я не знаю». У вас сложится впечатление, что он не знает вообще ничего. На самом деле, он просто не хочет брать на себя ответственность. «Думайте сами, решайте сами». И будьте готовы, как только вы принесете ему свои труды, он тут же превратится в знайку — и утопит вас своей критикой в формате «это не так», «а я то думал» и «ну, что же ты, Иглесиас».
5. Домсовет — коллегиальный орган, принимающий решение. Вы приходите, и для вас собираются все: главный, маркетинг, «начальник транспортного цеха», «академик по котам» и все все, кому еще скучно. Договориться о чем-то конкретном с этим табором очень тяжело. Особенно сложно сдать им готовое решение.
   

Открытие новой рубрики. Задача 1

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

Я предлагаю Вам поддержатьменя и совместно порешать эти задачи, которые могут помочь и Вам в трудную минуту.

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

И так, приступим.

Задача 1.
Клиенту разрабатывается сайт. В общем объеме работ по которому, есть пункт: "разработка flash-баннера", который может быть размещен как на самом будущем сайте, так и на любой рекламной площадке.

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

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

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

Вопросы:

1. Как на Ваш взгляд должен поступить руководитель проекта в данной ситуации?
2. как сделать так, чтобы впредь постараться застраховать себя от подобных ситуаций?
3. Стоит ли вообще, начинать работу с таким клиентом если еще на этапе продаж становится понятным, что это проблемный Заказчик?
   

10 основных ошибок при управлении WEB-проектами

Работу по созданию Web-сайта можно условно разделить на три основные составляющие:

• Создание информационного наполнения (содержание страниц, тексты, видео, аудио, мультимедийных презентаций и т.д.)
• Разработка элементов интерактивности (навигационная поддержка, раскладка страниц, шаблоны, возможности поиска)
• Управление процессом построения Web-сайта
  

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

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

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

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

Потребности не сформулированы

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

Другое дело, что формулирование потребностей в форме емкой фразы "Чтобы было" тоже бывает оправдано. Можно предположить, что сегодня наличие Web-сайта является частью имиджа современной и профессионально работающей компании. Таким образом, во многих случаях создание сайта по принципу "визитной карточки" или "рекламного буклета" с минимальным набором корпоративной информации, например, описанием компании, картой проезда к офисам и/или магазинам и годовым финансовым отчетом, является оправданным. Однако необходимо понимать, что подобное использование возможностей Интернет скорее всего не будет эффективным и должно быть результатом продуманного решения не вкладывать ресурсы в использование Web для бизнеса.

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

Основной потребитель сайта - непосредственный начальник

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

Структура сайта повторяет организационную структуру предприятия

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

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

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

Привлечение большого количества внешних исполнителей

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

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

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

На информационную поддержку забыли выделить бюджет

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

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

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

Web рассматривается как вторичное средство информации

Нельзя приготовить хорошее блюдо из остатков вчерашнего обеда. Точно так же нельзя эффективно использовать методологию и материалы, использованные в традиционных средствах массовой информации в Интернет. Web является новым средством массовой информации. Он отличается от телевидения, от печатных изданий и от глянцевых брошюр. Это значит, что нельзя построить хороший сайт на основе материалов, оптимизированных под традиционные средства информации. Аналогия начала века сегодня приобретает новый смысл: нельзя создать кинофильм просто установив кинокамеру на лучшем месте в зрительном зале кинотеатра…

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

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

Упущенные возможности гипертекста

Web является гипертекстовой средой. Ссылки связывают отдельные его элементы воедино и дают возможность пользователям найти новую и полезную информацию. Большинство компаний переносят это и во внешний мир, размещая URL своего сайта во всех рекламных материалах, видео-роликах, пресс-релизах, и даже в самих продуктах. Никогда не покупали, например, майку с URL на бирке? Зайдите в ближайший Levi's.

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

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

Интернет и Интранет сайты объединены в один

Внутренний Интранет сайт должен управляться принципиально по-другому, нежели публичный Интернет сайт. Ключевым отличием является то, что у компании обычно только одна внутренняя Интранет система и сохранить ее целостность и последовательность развития достаточно просто. Вечную проблему выбора браузера можно решить простым указанием соответствующего продукта в качестве корпоративного стандарта для доступа в Интранет систему. А необходимые дополнительные компоненты или plug-in можно централизованно распространять через систему администрирования локальной сети.

Сотрудники используют Интранет для повышения корпоративной продуктивности - с этим никто не поспорит. Значит, любая задержка при получении информации пользователями внутри компании считается прямыми убытками. Как Вам в этом контексте понравится идея размещения рекламы в корпоративных Интранет-сетях для того, чтобы окупить стоимость оборудования или программного решения? Элементарный подсчет показывает иллюзорность выгоды. Если, например, стоимость одной минуты работы сотрудника составляет $1, и пользователь тратит лишние 3 секунды на страницу с размещенной на нем рекламой, тогда каждый показ рекламы будет стоить компании 5 центов в виде потерь продуктивности сотрудника. Даже если информационный отдел экономит на рекламе 2 цента на каждом показе баннера (CPM должен быть на уровне $20, что само по себе сложно даже для такой благодатной целевой аудитории, как корпоративные пользователи), компания будет терять как минимум 3 цента на каждом показе.

Маркетинговые исследования и логическое проектирование - это не одно и то же

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

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

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

Можно использовать профессиональное маркетинговое агентство, которое опросит тысячи людей и узнает у них насколько им нравится Ваш сайт по сравнению с Вашими конкурентами. Когда Вы получите результат, что Ваш сайт имеет оценку, скажем, 5.6, а худший из сайтов конкурентов имеет оценку 5.9, Вы будете знать, что необходимо что-то улучшить, однако что именно и как - этого Вы узнать не сможете. Лучше проследить за реальной работой 4-5 независимых пользователей на Вашем сайте и заново трезво оценить его дизайн, а также те части, которые требуют совершенствования, потому что они вводят пользователей в заблуждение или тормозят его работу. Пара дней на логическое проектирование и Вы получите длинный список необходимых усовершенствований и изменений, которые значительно повысят полезность Вашего сайта.

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

Недооценка стратегической роли Web

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

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

Две классические ошибки в предсказании будущего технологического развития, это переоценка кратковременных результатов и недооценка его долгосрочных результатов. Люди от Web напустили столько пыли в глаза деловой общественности, что последние очень сильно переоценивают, что реально может дать Интернет бизнесу в ближайшие год-два: большинство сайтов не будут приносить своим хозяевам ощутимой прибыли в краткосрочной перспективе. Однако не упускайте из виду что может произойти когда размеры и возможности Интернет достигнут определенного порога. Эффективность использования сети возрастает как минимум в квадратичной пропорции от количества новых подключений, а реальный эффект для глобальной экономики будет виден после перестройки традиционных бизнес-процессов в среде большинства компаний.

Источник: БВБ

Deadline. Роман об управлении проектами

Еще представляю одну книгу "Deadline. Роман об управлении проектами" автора Тома ДеМарко.

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

Книга адресована менеджерам по управлению проектами в области информационных технологий.

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

Джоэл о программировании

Не так давно, в магазинах нашего славного города появилась книга Джоэла Спольски "Джоэл о программировании". Появилась и пропала. А книга очень интересная и полезная всем тем, кто так или иначе связан с софтверным бизнесом.

Книга представляет собой подборку эссе, опубликованных автором на его сайте http://www.joelonsoftware.com. Талант и глубокое проникновение в суть предмета сделали Джоэла мастером своего дела, а остроумие и едкий юмор принесли сайту скандальную известность среди программистов. Затронуты практически все вообразимые аспекты создания ПО от лучших способов устройства рабочего места программиста до лучших способов написания программного кода. Издание адресовано широкому кругу читателей - и тем, кто собирается руководить программистами, и самим программистам - как приверженцам Microsoft, так и сторонникам движения Open Source.

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

Вот такое длинное и замысловатое название.

Книга переведена и издана издательством Символ-Плюс и как это бывает, внешне претерпела значительные изменения по сравнению со своим заокеанским аналогом.

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

О том, что надо делать с опозданиями

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

Говоря такие крамольные для некоторых менеджеров слова, я имею в виду, конечно, компании нашей отрасли. Если мы возьмем для примера завод, где работает большой и всесильный конвеер, то получится, что прийти “в свое время” означает прийти всем в одно и тоже время. Конвеер не двинется с места пока все детали этой огромной технологической цепочки не займут своего места. Первый рабочий вставляет болты в пазы, второй закручивает, третий докручивает с усилием… Все производственные процессы разбиты на мелкие несложные операции.

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

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

Я почему говорю о штрафах. Приходилось бывать и слышать о совещаниях, где обсуждаются вопросы опозданий сотрудников на работу. Когда общими усилиями менеджеры решают, что приходить надо с 9:00 до 9:30, то тут же встает другой вопрос: “Что делать с теми кто опаздывает?”

– Надо штрафовать! — говорят одни.

– Вплоть до увольнения. — вторят другие.

А если взять конкретный пример? Получится так, что ведущий дизайнер, талантливый как Сальвадор Дали, опаздывает хуже всех. И что с ним делать? Штрафовать вплоть до увольнения? Ха. Кто же даст это сделать!

Вот и получается тупик. А все потому что “в свое время”, это когда надо для всех, а не когда кому-то так хочется. Человек должен успевать к процессу, а не к завтраку.

Источник: http://yuri.shilyaev.com/

Проблема опоздания в т.н. “наших конторах” вещь постоянная и часто трудно контролируемая. Я полностью согласен с Юрием, который говорит: “Программиста порой приходится искать несколько месяцев, требования к сотрудникам бывают довольно высокие, как следствие, применить штрафные санкции (такие как увольнение) бывает весьма сложно или невозможно в принципе. Надо подходить творчески.”

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

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

JIRA – багтрекер для широкого круга задач

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

Atlassian JIRA (http://www.atlassian.com/software/jira/) – система чуть более широкая, чем только багтрекер, это Issue Tracking system – то есть система трекинга сообщений как таковых.

Что умеет создавать:
Сообщения с определённым (управляемым администратором) набором полей, в том числе, такими распространёнными как: тип (ошибка, предложение, задание – список расширяем) ; responsibility (Assignie) – ответственный, получатель сообщения; приоритет; воспроизводимость; компоненты (очень удобная штука, если проект состоит из нескольких модулей или подсистем); версия в которой создаётся сообщение (affected version); версия в которой сообщение будет снова иметь силу (fixed version) – словом, стандартный набор полей для багтрекера. Стандартный, но при этом расширяемый для каждого проекта. То есть система ведёт несколько проектов с непересекающейся версионностью и своим уникальным набором полей.

Как происходит трекинг:
Создаваясь, сообщение обязательно имеет Assignie – ответственного, адресата (если такового не указать система в зависимости от настроек конкретного проекта либо автоматом «направит» сообщение, то есть адресует его, лидеру проекта (указывается при создании проекта), либо укажет необходимость выбрать адресата, если проект настроен так, чтобы сообщения не могли быть безадресными. «Получатель» может перенаправить его далее или вернуть писавшему ("петля разработчик-тестировщик").

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

Сообщения можно установить статус IN PROGRESS – в начале работы над ним, и соответственно указав, когда работы над ним закончены.
Особо хочется указать на работу с версиями и статусами с точки зрения просмотра списков сообщений. Система поддерживает возможность создания персонифицированных

Аттачи:
Небольшое приятное дополнение к опции «Attach Files», особо нужное если работаешь под «голой» операционкой, на которой нет средств редактирования и сохранения изображений (или как в случае с маком – такие средства есть, но пользоваться ими вин-пользователю неудобно жутко, да кроме того потом нужно ещё суметь достучаться по сети до сетевого ресурса, с которого потом этот файл можно будет приаатачить к сообщению об ошибке) – опция "Attach screenshot". Аттачить скриншоты, то есть буквально то, что на данный момент снято в буфер обмена, можно прямо в JIRA, с помощью небольшого java апплета, который отлично работает и под вин-системами и под маком. Согласитесь, удобно.

Аттачить можно не только картинки, но и доугие форматы файлов, однако если аттачить gif, jpg или bmp JIRA сама при просмотре сообщения сделать для них превьюшки. Это просто и удобно, ведь никто не гарантирует, что разработчик просматривая это сообщение будет иметь под что-то, кроме браузера.

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

Безопасность:
Умеет создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект.

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

Чем JIRA подходит нам:
У нас много проектов и команда тестирования работает одновременно с несколькими проектами и командами разработки. Кроме этого, мы работаем под несколькими типами операционных систем, в том числе и такой недружелюбной для тестирования как MAC OS. Особые правила обработки сообщений и оповещений для различных проектов, свободно уживаются в JIRA, не конфликтуя и давая возможность гибко ими управлять. Об удобстве работы с аттачами из под различных тестовых окружений, я писал выше. Различаются и требования к схемам оповещения и политики доступа и безопасности – со всем этим JIRA справляется легко, и как-то естественно. Чувствуется, что людям, которые принимали участие в её проектировании приходилось работать в нашем режиме.

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

Источник: http://notes.software-testing.ru/jira.htm

Проведение совещаний от Google

Вице-президент компании Марисса Майер проводит, в среднем, по 70 совещаний в неделю. Это и неудивительно, ведь она играет роль главного посредника между многочисленными группами разработчиков Google и руководством компании. Сергей Брин и Ларри Пейдж встречаются с Мариссой каждый день.

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

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

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

3. Микро-совещания. В рамках длительных заседаний можно организовать ряд краткосрочных сессий по 5-10 минут на конкретные темы. Подобная «модульная» структура совещания позволяет легко изменить план мероприятия, если возникнет такая необходимость. Дело в том, что в календаре Мариссы Майер минимальные отрезки времени имеют продолжительность в 30 минут. В такой график трудно вклиниться. Единственный выход — 10-минутные блоки.

4. Индивидуальный прием. Каждый день после 16:00 Марисса Майер в течение 90 минут принимает к себе посетителей из числа сотрудников. Это небольшие встречи тет-а-тет, где можно решить текущие вопросы без предварительного расписания. Сотрудники приходят к вице-президенту, чтобы согласовать дизайн программы или, например, поделиться собственными интересными разработками. Именно на приеме у Мариссы были впервые показаны и одобрены такие проекты, как Google News, Orku tи Google Desktop. За полтора часа Марисса Майер успевает провести до пятнадцати встреч.

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

6. Гигантский таймер. Большие часы на стене должны создавать некое психологическое давление на участников совещания. Таймер отсчитывает время, которое осталось до окончания совещания.

Кстати говоря, многие из этих правил используются не только в компании Google. Например, на недавней конференции Yahoo! Open Hack Day более полусотни хакеров выступили с небольшими демонстрациями своих разработок, при этом каждый имел по 90 секунд времени, а таймер отсчитывал время на стене. Такая система действительно очень эффективна.

Источник: http://www.habrahabr.ru/

Управление в стиле фанк

Я решил изменить название популярной книги "Бизнес в стиле фанк. Капитал пляшет под дудку таланта" авторов Кейл Нордстрема и Йонас Риддерстрэйла (кому интересно на Озоне можно купить эту книгу. В данный момент я дочитываю её и решил выкладывать блоги некоторые выдержки, которые мне наиболее понравились. Вот первая из них.

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

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

Служба мертва. Мы больше не верим в кусочек бумажки, на котором написано "Должностная инструкция". Новая реальность требует гораздо большей гибкости. На протяжении почти всего XX века большинство менеджеров имели только одну работу и только одну карьеру. Теперь мы можем смело говорить о двух карьерах и работе на семерых работодателей в течение жизни. Времена верных и преданных компании служащих давно прошли. Скоро в центре внимания будет стиль жизни, а не карьера, и работа будет представляться вереницей проектов и великих начинаний.

Идея конечно же не нова, о подобном пишет и Джоэль Спольски, но приятно то что эту книгу все чаще и чаще читают топ-менеджеры и многое активно начинают применять, а соответсвенно и отношение к коллективу.

10 способов провалить проект

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

Десять шагов к саботажу проекта, над которым вы работаете:

1. Начните проектирование с нуля. Ни в коем случае не используйте в качестве основы проекта готовый и работающий код. “Все удачные большие системы являются результатом перепроектирования некоторых меньших работающих систем. Я не знаю исключений из этого правила. Можно привести множество примеров проектов, закончившихся неудачей, над которыми мучились годами, тратили большие средства, и наконец успешно заканчивали, но спустя годы после намеченного срока.” (Б. Страуструп)
2. Никогда не размышляйте в процессе дизайна приложения. Найдите какой-нибудь список правил для проектировщика и безоговорочно ему следуйте. Любые решения, принятые самостоятельно, - это риск создать успешный проект.
3. Никогда не тестируйте свой код или откладывайте это до последнего. Программы, которые не тестировали, не работают. Чем позже вы начнете тестировать свой проект, тем больше вероятность, что он так никогда и не заработает должным образом.
4. Откладывайте релиз настолько, насколько это вообще возможно. Ведь вы разработчик и только вы знаете, что должен представлять собой ваш проект. Мнение пользователей, особенно на ранних стадиях, только вредит разработке вашего проекта.
5. Добавляйте в код все “фичи”, которые только можете вообразить. Создавайте ветвистые диалоги настройки, где для изменения любой опции нужно проделать не менее десяти шагов. Пользователи будут искренне рады каждой крутой возможности, которую они так никогда и не найдут.
6. Используйте готовые библиотеки только в самом крайнем случае. Всегда лучше написать все самостоятельно. Если перед вами стоит выбор между использованием готовой работающей библиотеки, которую нужно лишь слегка подправить, и написанием собственной, не задумываясь выбирайте последнее. Как известно, все библиотеки пишут люди, на самом деле ничего не смыслящие в программировании.
7. С первых же строчек занимайтесь оптимизацией. Если вы где-то прочитали, что двойные кавычки медленнее одинарных, используйте везде только одинарные кавычки. Не стоит задумываться об оптимизации на уровне дизайна приложения. Это не потребуется, если вы будете заниматься микро-оптимизацией. Запомните: “несвоевременная оптимизация - корень всех зол” (Д. Кнут). Только с помощью такого рода оптимизаций вы сможете создать проект, который потом можно будет запустить только на суперкомпьютерах.
8. Никогда не документируйте свой код. Если же вас прижмет начальство, то пишите что-то вроде “This function do various stuff. See source code for more information.” Код, соответсвенно, запутывайте как это только возможно. Не дай бог кто-то, кроме вас, сможет в нем разобраться!
9. Выберите одного самого ценного заказчика и добавляйте только те возможности, которые он потребует. На пожелания остальных клиентов не обращайте ни малейшего внимания.
10. Не придусматривайте расширение возможностей вашей программы. Ведь вы создали самостоятельный продукт, прекрасный в своей завершенности. После окончательного релиза, устроившего вашего самого ценного заказчика (см. выше) можно смело стирать исходный код: добавить к вашему творению больше нечего.
    

Источник: http://webdeveloper.net.ru

Об управлении программистами

Настоятельно советую, всем начинающим руководителям интернет-проектов, да в принципе и не только интернет, прочитать ниже приведенную статью Игоря Ашманова "Правила Ашманова. Часть 1". Я её размещаю в немного урезанном варианте, но со своими комментариями. Полный вариант вы можете прочесть, здесь. Да, вы спросите почему начинающим, да в принципе не почему, просто руководители с опытом более 2-х лет, подобные правила могут составить уже самостоятельно :)

Правило 1. Не бывает технических проблем. Бывают только человеческие, то есть организационные.

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

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

Правило 2. Технический жаргон ничего не значит.

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

Подобный жаргон лучше знать, но стараться общаться именно нормальным языком.

Правило 3. Разработчики всегда называют неверные сроки.
Нельзя верить срокам, которые называют программисты. Обычно их следует умножать на Пи. Иногда (редко) - делить на Пи. Выбор правильного действия руководителя над называемыми сроками зависит от личности разработчика. Это знание приходит к менеджеру только после нескольких экспериментов именно с этим разработчиком.

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

Правило 4. Разработчику свойственен врожденный оптимизм.
Средний разработчик всегда добросовестно заблуждается относительно трудоемкости задачи, обычно в меньшую сторону, поэтому его нельзя уличить или разоблачить. Более того, он никогда не учится на ошибках и постоянно повторяет одну и ту же ошибку занижения сроков, поэтому его бесполезно стыдить или воспитывать. Категорически нельзя рассчитывать, что уж на этот раз битый жизнью разработчик наконец-то называет реальные сроки.
Типичный признак необъезженного разработчика-оптимиста - самоуверенность и горячность, стремление пойти и сделать, а не сесть и запланировать.

Быть внимательным и всегда помнить о возможности такого положения. А лучше если руководитель постарается вместе с разработчиком составить план работы и детально разобрать задачу. Но только не брать этот процесс на свои плечи, это должен сделать сам программист, а руководитель только для помощи и контроля.

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

Четко и максимально понятное и временно отрегулированное ТЗ должно спасти ситуацию.

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

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

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

Правило 8. Разработчик не интересуется бизнесом, он - типичный автор.
Разработчик в среднем не стремится помочь организовать и развить бизнес, именно поэтому он не любит тестирования, считает пользователей идиотами, поэтому его трудно заставить документировать и поддерживать уже сделанные системы и программы.
Истинные личные мотивы большинства разработчиков - авторские, то есть включают интересную работу, хорошие гонорары и известность. Низовой разработчик может не иметь даже и авторских амбиций, и интересоваться только работой и зарплатой. Успех продукта или компании в смысле роста прибыли интересует разработчика только опосредованно.
Это нормально, так как авторские мотивы - очень мощные и их можно правильно использовать с большой пользой для компании.

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

Не видал ли где на свете Ты зарплаты годовой?

Сегодня пятница и меня что-то понесло на поэтику :) Увы не знаю автора этих строк, а то бы пожал руку ;)

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

Аль откажешь мне в ответе?
Не видал ли где на свете
Ты зарплаты годовой?
Я ищу её…
- Постой!..

Есть на севере гора,
В ней глубокая нора,
В той норе на трёх канатах
Гроб качается из злата.

В том гробу твоя ЗАРПЛАТА!

Источник: http://www.wormhole.ru/

Люблю я работу, зарплату люблю!

Люблю я работу, зарплату люблю!
Все больше себя я на этом ловлю.
Люблю я и босса — он лучше других!
И боссова босса, и всех остальных.
Люблю я свой офис, его размещенье.
А к отпуску чувствую я отвращенье.
Бумажки, в которых, как в бога, я верую!
Люблю я и равных мне по положению,
Их хитрые взгляды, насмешки, глумления.
Мой славный дисплей и компьютер я лично
Украдкой целую, хоть им безразлично.
Я счастлив быть здесь и пока не ослаб
Любимой работы счастливейший раб.
Я нормы и сроки работ обожаю,
Люблю совещанья, хоть там засыпаю.
Люблю я работу — скажу без затей!
И этих нарядных, всех в белом людей,
Пришедших сегодня меня навестить,
С желаньем куда-то меня поместить.

С нелюбимыми не расставайтесь

Иногда бывает так, что приходится принимать решение об увольнении сотрудника. Думаю, многие это делали. Трудно, понимаю… особенно если вы – руководитель небольшой компании или отдела, где отношения выстроены как в семье. Но увольнять всё же приходится, потому что по-другому бывает уже никак.

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

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

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

Многие скажут: «Ну вот заладил по-хорошему да по-хорошему. А как это по-хорошему?»
А вот как!

1. Если Вы намереваетесь кого-то уволить, подготовьтесь к этому: вспомните все положительные моменты работы этого человека, а также и отрицательные (думаю о них Вы не забудете:-D), ещё раз проанализируйте всё это и решите для себя, правильно ли Вы поступаете. Ответ положительный? Следуем дальше…
2. Подумайте, а где бы мог бы быть полезен этот человек, где его КПД будет выше (конечно не в Вашей компании;-)). Бывает, что человек вырабатывает свой ресурс на определённой должности либо он изначально не верно определился со сферой деятельности, либо не успевает перестраиваться в след за изменениями бизнес-процессов компании, либо он просто не может работать в том темпе и с той отдачей, которую требует сложившаяся ситуация. Это совсем не означает, что человек плох. Соответственно ему нужно помочь – предложить варианты, где бы он мог лучше себя проявить. Подумайте о своих знакомых, друзьях, хороших клиентах – может быть, среди них он найдёт своё место.
3. Никогда не говорите человеку, что Вы его хотите уволить, «сидя за столом», как начальник и подчинённый. Лучше создайте неформальную атмосферу - например, сходите вместе на обед, и там, в спокойной обстановке, максимально откровенно поговорите с ним.
4. При разговоре ни в коем случае не надо с первых минут заводить беседу об увольнении, лучше плавно подведите его к этой теме, попутно объясняя, из чего сложилось ваше решение, не забудьте отметить положительные моменты работы этого человека в компании.
5. Как вариант можно предложить человеку продолжить с Вами работать как внештатный сотрудник.
6. Не запрещайте человеку после увольнения приходить в офис к своим друзьям, приятелям, а также на корпоративные мероприятия – пусть он продолжает поддерживать хорошие отношения как с отдельными сотрудниками, так и с компанией в общем.
7. Скажите ему, что он может обращаться к Вам за помощью, и Вы ему обязательно поможете если не делом, то уж советом точно:-P.

В итоге даже уволив человека из компании, Вы не получите обиженного человека, «врага», а обретете

• будущего конкурента, лояльно настроенного к компании и к Вам лично
• потенциального заказчика
• партнёра.
  

10 шагов для очистки от информационного загрязнения

"10 шагов для очистки от информационного загрязнения" от Якоб Нильсена

1. Не проверяйте свою электронную почту по много раз на дню. Назначьте специальные промежутки времени между выполнением важных проектов для проверки своей почты. Не позволяйте e-mail прерывать ваши проекты и не позволяйте компьютеру устанавливать ваши приоритеты. Отключите функцию оповещения по поступлении новых сообщений в свой почтовый ящик. Если вы используете Microsoft Outlook, жмите на Сервис => Параметры => Параметры почты => Дополнительные параметры и снимите галочку с "Отображать оповещение на рабочем столе для новых писем".

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

3. Пишите информативные заголовки для своих e-mail сообщений. Допустите, что получатель вашего письма слишком занят, чтобы открывать сообщение с таким неубедительным заголовкам, как например "Привет".

4. Создайте отдельный ящик для личной почты и почтовых рассылок. Проверяйте этот ящик один раз в день. Если вы достаточно искушенный в использовании фильтров, используйте фильтры для сортировки и расстановки приоритетов в своей почте. К сожалению, это до сих пор является слишком сложным для среднего пользователя.

5. Пишите коротко. Стиль Дж. К. Роулинг - не лучшая ролевая модель для написания e-mail сообщений.

6. Избегайте интернет-пейджеров (instant messaging) кроме тех случаев, когда общение в реальном времени действительно не добавит ценности для коммуникации. Одноминутное прерывание ваших коллег будет стоить им десяти минут продуктивности, пока они настроят свой умственный настрой и смогут вернуться "в поток". Только самые важные сообщения стоят 1000 процентов в накладных расходах.

Полностью статью Нильсена в оригинале можно прочитать здесь.

Подумайте о разработчиках

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

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

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

".. выйти из зоны очень легко. Шум, телефонные звонки, сходить пообедать или сгонять в Старбакс за чашечкой кофе, назойливость сотрудников — ох, уж эти сотрудники — всё выбивает из колеи. Если коллега прерывает вас своим вопросом на минутку, и тем самым сбивает вашу концентрацию на полчаса, общая продуктивность труда серьёзно страдает. А в шумной, нервозной атмосфере, вроде того базара, что царит в интернет-изданиях (да часто и в web-студиях, где руководители проектов, а иногда и менеджеры сидят в одной комнате с разработчиками), а, когда продавцы-маркетоиды :) орут в телефон прямо над ухом программиста, производительность труда резко падает, потому что творческие работники находятся не в зоне концентрации, а в зоне постоянных помех. ... Однако же, войти в "зону" нелегко. Измерения показывают, что с начала работы максимальная продуктивность достигается в среднем за 15 минут. А если, кто устал или уже как следует поработал головой, то, бывает, никак не может войти в зону, и проводит остаток дня в интернете, играет в тетрис, бьёт баклуши... " - пишет Джоэль. А результатом всего этого являются затянутые сроки реализации того или иного программного модуля, куча багов и недоделок, частые стрессы и апатия к работе. В конечном счете, страдают все: от руководителя проекта до Заказчика.

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

Принимаю предложения :)