Прослушал аудиокнигу "Мифы о коммуникациях"

Очередная книжка о том, как общаться, верней о том, как мы воспринимает общение, и как оно есть на самом деле)

Очень короткая книжка (всего-то минут 50), помнится прослушал ее за 1 день пока шел на работу (да и вобще больше на статью тянет, чем на книгу), и пока шел с нее, потому в принципе ее не составит труда осилить даже тем, кто вобще не читает\слушает книги =)
Даже чувствую некоторое недовыполнение плана по прочтению книг на этот месяц, думаю осилю еще что-нибудь до конца года =)

В книжке перечислены 6 мифов, когда мы уверенны, что доносим до собеседника именно, то что думаем, а не то, что говорим)
И почему-то не сомневаемся, что он воспримет через призму собственного настроения,
опыта и отношения к нам, именно то что мы хотели сказать:
Что ,сказав девушке "ягодка, моя" - она не ответит нам: "а за `арбуз` ответишь!".
Что промолчать - это тоже коммуникация, только мы сообщаем- "ты мне не интересен, мне пофиг на тебя".
Что войдя в комнату к боссу со своим супер-предложением после того, как он отчитал другого своего подчиненного мы выйдем победителем, а не нарисуем на своем собственном лбу мишень)
Да и просто о том, что человек слышит нас. а не то что он хочет услышать =)

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

Ссылка на озон: http://www.ozon.ru/context/detail/id/3411517/ (хотя, в гугле довольно легко находятся и бесплатные аналоги)

Спасибо за потраченное время и читайте книги =)

"Harvard Business Review" / Ведение переговоров и разрешение конфликтов.

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

Данная книга - выборка из 8 статей по тематике переговоров:
1)"Урегулирование разногласий" Роберта Танненбаума и Уоренна Шмидта
2)"Команда, которой не было" Сюзи Уэтлауфер
3)"Как пожить конец войне группировок" Роберт Блейк, Джейн Моутон
4)"Переговоры с клиентом, которого нельзя потерять" Томас Кайзер
5)"Как превратить искусство ведения переговоров в корпоративный потенциал" Дэнни Эртел
6)"Анатомия конфликта между клиентам и консультантом"  Айделин Кейснер
7)"Пять способов не довести дело до суда" Джон Эллисон
8)"Альтернативное разрешение споров: почему в одних случаях оно результативно а в других - нет?" Тодд Карвер, Альберт Вондра.

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

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

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

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

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

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

Седьмая статья рассказывает об  способах и выгодах АРС(альтернативных разрешений конфликтов), т.к. судебное разрешение может длиться годами, стоить много денег обеим сторонам и в итоге даже выигравший за время тяжбы потеряет больше ресурсов, чем выйграет.
Не уверен на сколько сильно это применимо к нашей стране,  т.к. судебная система у нас не столь мощна и всеобъемлюща, как в США.
Хорошей иллюстрацией такой системы является суд в Израиле: при рассмотрении дела о разводе между мужем и женой. Жена жаловалась, что любит мужа, но т.к. они бедны  то живут с матерью мужа, они - на втором этаже, а мать - на первом. И мать ее мужа постоянно когда женщина возвращалась с работы домой и проходила через первый этаж донимала ее придирками и вопросами и ее это так достало, что она хотела развода. В итоге, посовещавшись судья вынесли вердикт: мужу - купить лестницу, чтоб жена когда хочет могла не проходить через первый этаж, а влезать сразу на второй через окно =)
Вот такое вот альтернативное решение делу)

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

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

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

Отчет об посещении питерской SpmConf.

В прошедшую субботу (26 ноября) состоялась Software Project Management Conference. И прошла удачно) С кучей маститых и известных докладчиков, и парой-тройкой знакомых по твиттерам-блогам лиц)

Да и прошла для разнообразия не в Москве, а в Питере, что тоже по своему хорошо =) Своеобразный город, где еще люди, еще отмечающие пятницу, с утра субботы в баре угостят кофе (рано приехал к 6-7 к отелю и потому зашел в ближайшую по гугл-мапс кафе\забегаловку, где люди пили коньяк\пиво и играли в шахматы=)). А встречающаяся вечером пьющая алкоголь школота обсуждает Шопенгаура и поэзию 15 века =)

Вернусь к докладам и мои впечатлениям от конференции.

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

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

На половине доклада понял, что хоть и интересно но пользы я лично из этого не смогу (разве, что запомню, что когда нефть будет падать придется валить из страны =)).

Пошел послушать Максима Вишневского про отдельные вопросы анатомии менеджера, он рассказывал какие факапы и ошибки совершал в своей бурной пм-молодости, как переносил сроки проекта по 4 раза =) Переписывал проекты с нуля и все такое) Слушать развлекательно и забавно , но каждый в душе надеяться, что такие уж ошибки он то и не совершит) Хотя с другой стороны в конце доклада вышло, что совершить ошибки это хорошо - начинаешь понимать, что и где может пойти не так, приобретаешь опыт)

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

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

После Сергея краем уха послушал Вячеслава Нестерова (Генеральный Директор Санкт-Петербургского Центра Разаботки EMC), который рассказал, как их корпорация подходит к развитию своей инновационности, т.к. чувствует, что без инновационности - можно и отстать от конкурентов.
И поэтому докупает компании занимающиеся разработками продуктов на рубеже неизведанного (типа VmWare), и всячески поощряет коммуникацию и обмен знаниями среди своих подчиненных/
Круто, что большие корпорациии вобще задумываються об этом, с другой стороны доклад тоже достаточно специфичен и был бы интересен узкой категории, тех кто работает в похожих по размерам и глобальности компаниях)

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

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

Потом пошел слушать Михайла Завилейского из DataArt`a: сначала был небольшой скептицизм из-за очень уж "боянных" тезисов в программке типа: почему заставлять коллег соревноваться плохо.

Датаарт похоже своеобразная компания, т.к. управляется эдакой массовой рассылкой на 28 человек(топ-менеджмента), без какого-то особого лидерства и руководства, как говорил сам Михайл он бы сам не поверил, что такое работает, если бы не видел это в живую.

Если во многих книгах про великие компании говориться, что чтобы стать великими вам надо иметь принципы\миссию\вижен, то они действуют от обратного - никаких особых принципов (кроме никто не должен выполнять бесполезной работы): все вольны иметь свои убеждениям, главное толерантно к друг-другу относиться и это работает).
Т.к. на рынке, где кандидатов на работу мало, компании с особой политикой и принципами вынуждены отсеивать не подходящих им людей, а Датаарт спокойной набирает их и растет, то их позиция - намного выгоднее.
Было рассказано про то, что кнут в общем-то не всегда работает, как задумано: если у человека есть возможность заплатить штраф например за опоздания и он не слишком большой, то вы фактически даете ему возможность купить индульгенцию, т.к. штраф он вроде как заплатил и журить после этого за опоздания его уже глупо)
Повторил довольно известную мысль, что в общем-то KPI ведут к оптимизации KPI и скорее всего приведут к "игре" - "мы играем по таким то правилам, мои KPI упадут, если я тебе помогу так что - пока" =)
В общем доклад навел на 10к-другой полезных мыслей =) Прослушал с удовольствием наверно  и засчитал бы его в топ-3 по всей конференции)

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

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

После волны не особо интересных докладов, пошел слушать Григория Печенкина  об "Культурных различиях в IT", в общем-то обзорно прошлись по разным полюсам типа доверия\паранои, команда\лидер и т.д. Как обзорный доклад может и хорош, но какую-то финальную  мысль, кроме того, что вот мол бывает так и сяк я не особо уловил. Тролль-команда в лице Михаила Заборова из Custis`а и еще пара человек, задавала каверзные вопросы, чем слегка оживила его дискуссией в конце и показала наличие московской тролль-культуры =)

Параллельно чуть послушал Ольгу Павлову из UsabilityLab, которая успешно развенчивала мифы о том, что Hr`ы важны и нужны(от коих на конференции было минимум 3 доклада, на которых они активно рассказывали почему не надо искать самому, а надо юзать их способности ) и нужны и рассказывала, как самим набирать программистов, менеджеров и прочих итшных личностей. Помню, что было вполне интересно и докладчица рассказывала в меру живу и интересно и даже приводила свою собственную систему hr-стайл GTD по найму.

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

один из этапов развития
матричной структуры

Что рано или поздно наличие матрицы и оптимизация ресурсов приведет к занятости 1,5 землекопа на проект, что крайне не эффективно и итогом этого развития, как не странно видятся готовые самоорганизующиеся кросс-функциональные команды (Внезапно, да ?)) =)

Было интересно послушать, как некоторый такой экскурс в историю, увидеть и понять как оно идет в типичном аутсорсере.
И тлеяла надежда узнать, что же там - за следующем level up`ом, но она не оправдалась)

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

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

Но гораздо интереснее были вторые участники в качестве "провинившегося сотрудника" выступил 1 из участников мастер-класса которые был настроен жестоко повоевать, перебивал пма, мастерски отмазывался, не хотел давать никаких обещаний, переносил разговоры на потом и т.д. Cотрудник-тролль-звезда в одном лице заставлял заливатсья хохотом весь зал так мастерски он уходил от ответственности и ответов на вопросы)
В итоге сам Дмитрий Башакин хотел показать, как надо доставлять обратную связь, но был им успешно затроллен в том числе =)
После по горячим следам разгорелась мини-дискуссия о том, что чтоб сотрудник мог вести себя ТАК, он либо должен быть незаменим либо сразу же уволен)

Предпоследним слушал доклад Дмитрия Безуглого про лестницу работы с потребностями потребителей, в какие-то идеи этого доклада я видел еще на ЛАФ`е (Летний Аналитический Фестиваль) и потому информация не была для меня совершенно новой.
Дмитрий разрабатывает свой фреймворк для создания продуктов для потребителей на основе идей Design Thinking собственного опыта и т.д. Цель которого создавать такой продукт, который может не только показаться интересным потребителю на неделю чтоб поиграться и уйти к конкуренту, но и чтобы покрыть его скрытые потребности типа ощущения себя себя избранным от работы с вещью, а не только от выполнения ею базовых полезных функций.
Довольно тяжело сформулировать всю концепцию словами, но будем надеяться видео с конференции появится в ближайшем будущем. Думаю доклад был бы интересен product менеджерам.

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

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

Стиль Стаса не передать словами, это эдакая веселые откровения наполненный глубокомысленной философией =) Надеюсь, что когда нить я все таки наткнусь на полную версию его доклада и посмотрю =)

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

Спасибо, что дочитали до конца, удачного вам дня. Увидимся на следующей #spmconf !

Мини-отчет по #wudru.

В прошедшие выходные прошел World Usability Day по русски то-бишь wud.ru.

Прошло вполне себе живенько и в целом не плохо)
Заметил за собой, что не хотелось слушать всего лишь пару докладов - большое достижение для любой конференции)
Организационно устроились хорошо в принципе 1 большой класс + комнатка для мастер-классов - интересный формат, во время мастер классов в нее забивалось больше, чем нужно людей, поэтому она могла быть еще помельче =)

Первый доклад помню вобще плохо (искренее соболезную докладчику, т.к. все еще наверно сонные были пока пришли =)), ну и да ладно - не запомнилось - значит было не интересно =)

Юра Ветров рассказал ОЧЕНЬ быстро, я хоть в теме и до этого был про design thinking (т.к. участвовал в мастер-классе на ЛАФе) доклад было слушать довольно сложно, и думаю стороннему человеку услышавшему его в первый раз было б вобще не понятно о чем это.

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


Убег от них на 4 шаге великой эпопеи изобретения телевиденья будущего, и ушел послушать Алишера Якупова из Одноклассников с его "Эффектом модерации". 


Алишер рассказывать умеет и видимо любит: весело, задорно с объяснением -  что и почему, и с прокачанным скиллом "Dress your numbers" прям, как по книжке про секреты презентации Джобса =) 
Рассказывал как создали игру-модерацию фоток с очками-деньгами, на покупку подарочков\сервисов "5+" и etc., что в итоге это дало еще больший положительный эффекта, т.к. модеры, что дали подарочки, в ответ тоже получали подарочки, т.к. подарки обязывали отвечать взаимностью - получался двойной профит - отмодеренные фотки и увеличение покупок подарков и сервисов, сливали они эти очки, через аукционы чтоб людям было на что их тратить + не было особой инфляции этой самой внутренней валюты, в общем один из полезнейших и интереснейших докладов был)


После Денси Бесков рассказывал о том, кто есть продукт менеджер, откуда он берется, что делает, и какими KPI измеряется и почему юзабелист хорошая кандидатура на его становление) С одной стороны он конечно слайды читал, за что самой презентации я бы сказал "ни зачет" =) С другой стороны тема участникам была интересна и потом вызывала много вопросов. Денис рассказал про широко известный в узких кругах "Pragmatic Marketing Framework" и что чтоб вырастить продукт менеджера говорят надо лет 10, но в принципе сам считает, что лет 3х достаточно) В общем тоже послушать интересно было) 


Потом был обед в результате которого пропустил доклад Стаса Фомина о чем жалею, т.к.вещи по всему собирался рассказывать интересные)  С обеда вернулся на Андрея Бибечева с Его "NUI(Natural User Interface)" было смешно и весело  вживую показывал интерфейс на Кинекте, листал слайды руками, показывал скелет человека, которым управлялся компьютер. Пытался голосом управлять но зафейлил, да и так смешно было =) За ними наверно будущее интерфейсов и думаю тема еще наберет популярность, но пока технологии не сильно развились еще можно расслабиться и не париться, над созданием гайдлайнов к Кинекту =)

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

Потом был доклад Маргариты Титовой про опыт использования удаленных пользователей(т.е. сервисов с ими ссамыми) для тестирования интерфейсов, слушал правда в пол-уха,т.к. иногда
бегал в зал мастер-классов послушать о чем там говорят: а там тоже говорили от "о дизайне, как маянезике" до "приорететы - `фичи` версус `простота`". У Маргариты, что понравилось доклад был о реальном опыте и с картинками из Большого Взрыва(как ни странно достаточно удачно подобранными) и хоть наверно и без откровений (а может и с ними, но я пропустил), но тоже интересный =)

Предпоследним был доклад Константина Кичинского про дизайн Windows Phone 7, как ни странно, хотя доклад и был так сказать "евангельский" наверно один из немногих докладов про действительно интерфейс и те или иные решения, к которым пришла команда разработки телефона по мере его эволюции. О том, как надо и как не надо делать приложения под виндовс-фон (хинт - айфоновский дизайн копировать не надо). Привел примеры как хорошо, и как плоха, и обьяснил почему это так. Думаю виндовс-фон тоже найдет своих любителей, как айфон с андройдами т.к. интересные идеи и решения у них есть. Самый "интерфейсный" доклад из всего потока, если так подумать =)


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


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


Надеюсь увидеть всех вас в следующем году в тоже время в каком-нибудь месте =) 

Презентации, как Стив Джобс.

Как сделать вот такую презентацию.

Как-то так получилось, что добрался до чтения этой книги(Секреты презентаций Стива Джобса, Кармин Галло) только после смерти самого Джобса.

Ну что ж можно считать, что теперь его произведения и выступления будут ценится, как картины мертвых художников :)

Не буду пересказывать книгу, т.к. лучше 1 раз увидеть, чем 100 раз услышать =) Лучше сразу расскажу почему и чем она была интересна.

Почему книгу стоит прочитать

Как только вы поднялись на одну ступень со дна, 

ваша эффективность зависит от способности

 достигать умов других людей 

с помощью письменного и устного слова.

Питер Друкер

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

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

Думаю и вам хочется, чтобы:

ваш продукт покупали 

или готовы были "купить" вас самих при собеседовании (умение договариваться уже практически требование в менеджерских и ИТ-вакансиях)   

или чтобы ваши идеи находили отзыв в сердцах коллег и клиентов,

или хотя бы уметь проще и понятнее донести свои мысли до окружающих. 

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

Этот парень, что-то знает.

Что в книге хорошего
Интерес. 
Ее интересно читать, видно, что автор сам воспользовался теми советами, что приводил. Ее чтение идёт прямо, как захватывающее художественное произведение.
К примеру часть книг, что я читаю, приходиться планировать в стиле "прочитать еще 50 страниц из книги Х со страницы Y"(на самом деле), т.к. они довольно скучно изложены и хотя и полезны, но могут быть только вот таким поеданием слона по кусочкам.

Эта же книга - из "прочитать 100 страниц" превратилась в "все таки оторваться от нее и сделать остальные дела из списка" =)
Множество историй из жизни, сравнения с другими известными ораторами, даже черт возьми статистика используемых слов показывает, как и почему Джобс делал такие успешные презентации.В общем - цепляет!

Про позу тоже важно не забывать.

Полезные советы и четкая структура.
Как и реальная презентация книга идет по шагам, фактически позволяет вам процесс создания презентации вместе с ней:

• задумка
• планирование
• подготовка и приукраска
• выполнение
• "holy shit" момент, когда пользователь понимает - вот она рыба моей мечты гениальность этой идеи!
• получить удовольствие 

Выполнить - отрефлексировать и отточить - повторить - профит =)
Что, где и как - написано с примерами, цитатами, в общем вы гарантированно запомните, в книжке даже есть пример для 1го из пунктов - "как бы я написал отзыв на эту книгу". 
Отзыв мне понравился - сразу захотелось прочитать книгу, а потом скопировать в блог =)

Простой деревенский парень - Стив

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

Ну и финальная цель выступления и самой презентации обозначена просто = "have fun" - получайте удовольствие от процесса!

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

P.S.
Краткий пересказ в слайдах книжки можно увидеть тут: презентация на слайдшаре (на английском) 

Иди и прочти!

О разработке требований

Бывало ли у вас, что непонятно, что должна делать эта фича\таска\проект ?
Бывало ли, что при чтении кода или работе с программой становилось непонятно: это бага или фича ?
Возникала ли у вас хоть раз мысль: "что этой формулировкой тут хотели сказать, %№:%№ ?!" ?
Случалось ли хоть раз, что заказчик говорил вам: "это не то, что я вам пояснял !!!" ?

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

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

В общем думаю без преувеличения можно сказать, что все это видели, видят и еще долго будут видеть в будущем =)

вот как-то так и работаем =)

К чему это я: за 30-40 лет существования более-менее коммерческой части ИТ мы научились делать сложные, большие, высоконадежные, масштабируемые, качественные системы, но до сих пор не научились понимать, ЧТО и ЗАЧЕМ надо все таки реализовать.А процент успешных проектов - так и остался на уровне 30-40 %, с небольшим ростом около 5% за последние годы.
Новые технологии не спасают, т.к. проблема так и осталась в людях - мы просто плохо представляем, что же они хотят получить от нашей системы в итоге.

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

И МНЕ ОТКРЫЛОСЬ!

Шучу конечно)) Ничего сверхестественного не открылось, но где потенциально профакапить можно стал понимать лучше)

Вобще данная книжка по праву должна считаться "настольной книгой аналитика" и скорее всего ваш аналитик читал ее, если нет - то пусть прочтет.
У вас нет аналитика ?
Но кто-то же выполняет его роль ? Разаботчики\ПМ\ПО\юзабелист\маркетолог ? 
Никто ?
А ну тогда ясно почему вам приходиться переделывать, что-то по 5 раз прежде, чем заказчик это примет.
Кто-то эту роль выполняет - если он выполняет ее неявно и тяп-ляп - вам же хуже.

И в интересах компании, чтоб кто-бы ни брал на себя обязанности аналитика, чтоб он мог сказать почему и зачем так реализована КАЖДАЯ фича в вашем продукте.


Хотя бы вскользь прочитав первую главу, вы поймете: КТО, ЧТО и ПОЧЕМУ.

Анонимные пользователи

Кто.

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


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


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

ЧТО ?!

Что и почему.

Что такое требования ?
Как их разрабатывать и как ими управлять?
Зачем ими заниматься ?
Почему у хороших людей могут появляться плохие требования?
Как отличить хорошие требования от плохих?
Как заметить, что какие-то требования пропустили?
Как требования разрастаются и как происходит их "золочение" ?

Если вы не можете ответить на хотя бы 1 из вопросов или возникает смутное ощещение, что вы не понимаете о чем это - значит вам надо прочитать 1ю главу, как минимум =)

Как.

Вторая глава посвящена правильной разработке требований.

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

Иначе позвольте задать вам пару вопросов:
Что такое бизнес-требования, как они превращаются в образ и границы проекта?
Как найти и отобрать этого скрытого пользователя, который точно знает, что же ему нужно от вашего продукта?
Как выпытать из него нужные сведенья с максимальной пользой, эффективностью и удовольствием для обоих сторон(интим не предлагать)?
Как понять, что то что вы услышали, действительно, то что надо, а не получить "качели" ?
Что такое бизнес правила и с чем их едят ?
Почему документация не такое уж и зло, и как применить это зло во благо ?
Что такое атрибуты качества ПО и как их выявить ?
Зачем создаются прототипы ?
Как утверждать требования ?
Какие бывают проблемы при разработке требований ?
Вы таки создал требования - что делать дальше ?)
Кто убил Кеннеди ?

На эти и тысячи других увлекательных вопросов вы сможете узнать в нашем супер-пупер издании, которое так же излечивает гемморой, головную боль. И в добавок если вы позвоните прямо сейчас, то получите ... супер приз - АВТОМОБИЛЬ!!!.

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

Куда.

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

Ну а так, как к этому моменту вы поймете насколько у вас все плохо, то 4я глава расскажет вам как реализовывать этот самый процесс построения требований =)

Кроме того для лентяев и тех кому все таки лень читать книжку в ее конце есть пара приложений, с целью само проверки насколько хорошо вы управляетесь с требованиями.
Вырезка из CMMI рассказывающая, как эти самые процессы совершенствовать.
И руководство по поиску  и решению проблем, связанных с требованиями (куча таблиц, показывающих, что 90% ваших ежедневных проблем - неправильная работа с требованиями=))
Ну и естественно пример, как оно должно быть =)

Приятного чтения.

Обзор книги Эрика Берна "Лидер и группа. О структуре и динамике организаций и групп"

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

Если имя автора вам ничего не говорит, то можно загуглить "транзакционный анализ" и "родитель-ребенок-взрослый". Узнаете кое-что полезное =)

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

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

С одной стороны знания почерпнутые из книги довольно сложно применить "в лоб", сказав что-то вроде: "с этого дня буду делать встречи 1 на 1". С другой такие обще-человеческие знания типа существования внешних и внутренних групповых границ (внутренняя - лидерский аппарат), существовании второстепенных границ, о том, что групповая динамика в принципе измеряется количественно, например, такими показателями, как сплоченность. О том, что бывает внешний и внутренний групповой процесс.

Группы можно классифицировать 10ками способов, а не просто "толпа коллег": по структурным, динамическим, рабочим, властным аспектами и т.д. "Коллеги за работой" и "толпа пьяных фанатов" - две группы но такие разные =)

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

Если по прохождению тренинга по командообразованию, мне было известно о двух типах руководителей "администратор" & "лидер", то теперь узнал что их 3:

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

В общем почвы для размышлений можно понабрать на месяц-другой =)

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

Третья и четвертая часть книги посвящена анализу индивида в группе(его потребностей, транзакций и игр) и прикладной социальной психиатрии, знание из которых может и было бы полезно просмотреть, но они уже скорее идут к чисто таким психиатрским скилам, что если честно в рамках расширения кругозора я бы посчитал овер-киллом =)

Итого: первую часть можно и нужно почитать, вторую чтоб на практическом примере понять как же оно работает, и получить в голове пару озарений в стиле "ага, вот оно что!", а третью и четвертую - только если вам реально интересно и есть свободное время =)

Октябрь - пора конференций

Good news everyone!

Удачное начало месяца (good news =)): удалось посетить парочку конференций в частности: более-менее технологическкий Highload  и скорее тусовочный 404fest =)


Начну в хронологическом порядке с мини-отчета по 404: 
Собственно особо чего-то нового от конференции не ожидал, т.к. поехал больше потусить и повидать знакомых и бывших коллег (из Parсsis, которые собственно поглотили турбомилк: организаторов 404). 
Судя по всему таких было немало, т.к. в твиттере проскакивали сообщения типа: "без докладов была б вобще отличная конференция")


В общем-то народ общался о всякой фигне, развлекался, пил алкоголь (который в виде айпад-приложения, и прилагающегося к нему барменом, был предоставлен plusmedia(определенно ГОРАЗДО лучший способ попиариться, чем стенд с надписью) =). 


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


1) доклад Кирилла Готовцева "Почему инвестор это существенно хуже чем кажется", мысль то в общем проста: инвестор - это тот чел, что в 90е смог отжать\удержать\заработать себе так много, что сейчас у него есть лишние деньги, и в общем-то сейчас вы все: программисты, дизайнеры, и т.д. ни разу не круты, чтоб с ним тягаться. 
И если ВДРУГ что-то пойдет не так, то будьте готовы растаться со всем: проектом, командой, идеей и т.д.,  т.к. этот чел, знает как и что забрать и удержать. 
С одной стороны вроде очевидность, но с другой - мало наверно кто об этом задумывается, когда строит планы: вот инвестиции рекой потекут и ламборджини через полгода куплю себе.


2) Очень понравился доклад Сергея Котерева "Театр абсурда или история измерений удобства веб-интерфейсов с помощью трофейного прибора Eye-Tracker" товарищ рассказал, как они применяют этот самый прибор для математически точного измерения юзабельности UMI.CMS и сравнения его с аналогами. 
Сколько кликов нужно, чтоб добавить новость, сколько секунд это занимает, где люди вобще ищут кнопку, как сделать, так чтоб кнопку редактировать вобще заметили. И на конец: "А нужна ли кнопка вобще" ?
Так например во время юзабилити тестирования кнопки "демо" на сайте обнаружилось, что женщинам-менеджерам вобще нафиг не сдалось демо: они читают описание и ищут телефон, чтоб позвонить и расспросить уже селза, так что как кнопку не выделяй по ней вобще не щелкают, а лучше телефон сделать виднее и понятнее.


3) Послушал ЕДИНСТВЕННЫЙ более-менее технологический доклад от Олега Шарова из Echo, рассказали про тяжелую жизнь калифорнийского стартапа, который боролся за рынок на котором даже и денег-то особо не было. Чуть рассказал о том, что у них 50 тачек риака + индексы на пострегресе(20 машин), а написано все на эрланге + окамле. Что сначала боролись с дискасом, то у них появилась фича - через неделю она на дискасе, то наоборот, хотя денег никто и не получает, и потмо они поняле, что это путь в никуда и превратились по большей части в риал-таймовую бд на основе который люди могут строить свои системы, ну и вроде как поперло. 


4) Интересно было послушать Александар Калугина из Mercury Development про "Большие проблемы маленьких устройств", разрабатывать под мобильные платформы не так легко, как кажеться, полд декстоп - гораздо легче: проблемы с лицензированием, жпсом, количеством памяти, 3-5 разными раскладками интерфейса под IOS, и десятками под андройд, про то, что бывают андройд-клиенты без тачпада - с клавиатурой, и там тоже это должно работать. Вобщем мобильная разработка - это такой себе отдельный мини-мир в разработке с кучей проблем и неочевидностей. Начинающим и не очень начинающим разработчикам под мобильные устройства: обязательно пообщаться с автором =) 


5) Достаточно интересный филофоски-образовательный доклад был от Петра Диденко из Скб Контура "Мы все конкурируем с бумагой" оказывается эти ребята разрабатывают "Диадок", систему замены бумажного документооборота, я про нее слушал от знакомых работающих в банках и обычно ничего хорошего =) Но оказалось, что в общем-то ребята пытаются решить одну проблему: избавить документооборот об бумаги вобще, т.к. по сути все документы щас создаются в электронном виде, а печатаются\передаются курьером\подписываются и т.д. лишь для отчетности перед государством. Послушать было интересно, хоть и безполезно =)


6) Послушал Евгений Кобзева из того же СКБ Контура про то какие данные можно достать в этих наших интернетиках о частных и юридических лицах, тоже интересно: о списках акционеров, уставных капиталах, кто где зареган, кто чем владеет, кто сколько доходов\прибыли получает: опять же считать чужое жутко интересно, но довольно безполезно: зато можно посмотреть а то, где я работаю прибыли то приносит: в этих данных зачастую всплываю "попилы": типа убытки -540 миллионов, но банки опять дают этому предприятию 500 миллионов кредитов. Бзеполезно, но забавно.


7) Последнее, что не досидел до конца из интересного было: "Customer Journey (неисповедимы пути потребителя)" от Андрея Сикорского. 
Планировали и думали, как конкретный потребитель попадает на конференцию. Какие ожидания у него формируются.
Что ему мешает найти нужную информацию или совершить нужное действие(барьеры): стоимость, документы, необходимость добраться до другого города.
Что его стимулирует продолжить путь к намеченной цели: темы докладов, фотоотчеты с предыдущих конференций, имена известных лиц, отзывы друзей и т.д. 
Что он ожидает после конфы: выкладывание отчетов ? выкладывание презентаций, возможность сконтактировать с понравившимися докладчиками и т.д.? 
В общем очень полезная деятельность - странно, что я не видел и не слышал, чтоб ее где-то применяли из более-менее известных мне компаний. Надо бы как-нибудь


Жаль до конца не досидел, т.к. надо было уже бежать на самолет(, который все равно зараза на 4 часа опаздал: Epic Fail!)


Еще была пара-тройка докладов, которые хотел послушать, но "не судьба" =)


В остальном все было обычно: людей хантили(особо островок.ру, думаю пару-тройку человек они нашли =)), старые знакомые знакомились, новые знакомые заводились, полеголые барышни пиарили Мегафон, кого-то там еще и т.д. в общем было весело =).





А теперь про highload++:


В принципе за его цену я ожидал большего, ГОРАЗДО большего. Но еда была отличной =)

Было наверно штук 7-8 западных докладчиков, но они либо пиарили свой продукт, либо рассказывали вещи из мануалов и туториалов на сайте. Русские докладчики рассказывали иногда что-то более-менее интересное, но это было скорее исключением:

Alvaro Videla пересказал мануал RabbitMq, т.к. я по него знал нового, ничего не всплыло.

Buddy Brewer заинтересовал только прикольным именем и фамилией, о чем он рассказывал я уже забыл даже =(.

Потом послушал Андрея Саса из Badoo про 100 миллионов писем в день - в принципе интересно, т.к. мало кому с такими объемами приходиться работать. особо чего-то не запомнил, но буду знать у кого спросить. 

Макс Лапшин из erlyvideo рассказал, как он перепроектировал свое приложений чтоб перейти от 800 клиентов слушающих видео к 3500, что в принципе это заняло всего-то неделю времени достаточно начинающего программиста и все благодаря эрлангу. Вобще докладов про эрланг или продукты на нем было 5-6 и думаю через пару-тройку лет он уже пойдет в мейнстрим. Думаю после конференции его подучат 10к-другой человек).

Потом был вкусный обед)

После этого послушал про mysql в Facebook`e от Domas Mituzas запомнилось, что у них сейчас 5.1 с кучей своих патчей, полезностей от которых в 5.5 еще нет, но вот в 5.6 добавят, что-то похожее и они на него перейдут, в основном патчи, связанные с производительностью, которые в чем-то дополняют, а в чем-то конкурируют с перконовскими сборками.

Послушал Роберта Вирдинга про реализацию эрланговской VM(Virtual Machine), в принципе все из рассказа уже где-то читал, да и думаю любой кто-хоть сколько-нибудь знаком с эрлангом знает о том, что garbafe collect происходит для каждого процесса, а не по аналогии я Явовским "Stop the world", что решение копировать память при пересылке сообщений - сделано для упрощения реализации этого самого GC. Из вроде-бы нового узнал, что есть такая штука, как erjang, краем уха слышал но не интересовался, т.е. реализация эрланга поверх явовской вм, дает ускорение на некоторых задачах(например число-дробительных), но привносит тот-самый "stop the world". Думаю тем, кто в первый раз слышал о эрланге было интересно.

Следующим был действительно интересный доклад Валентина Нечаева из ClustrixWatch про мониторинг кластеров супер-компьютеров. 

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

Потому мониторить - надо, но мониторить надо реал-таймово + реагировать очень быстро потому ос + тсп тут не особо подходят, т.к. у tcp могут быть довольно длинные задержки. Соответсвенно выход - удп, + собственный биос, который цепляется к шине данных материнки и отслеживает подозрительные события и шлет их супервайзерам (написанным на основе эрланговского OTP).Т.к. событий даже в 10000-ядерном кластере миллионы, все это шардится и судя по всему устроено так же, как дерево супервайзеров в эрланге. 

Половину доклада я,вероятно, переврал, но суть кажется передал) 

В общем 1 из интереснейших докладов.

Пару последних докладов первого дня я пропустил, хотя хотел послушать и потмо вернулся только на фуршет) Опять же поили и кормили вкусно =) 

После фуршета отправились с группой товарищей из Новосибирска (работают в 2Гис) и парой Московских знакомых в Тарас Бульбу неподалеку) 

Обсудили конференцию: не понравилось, что фирм не написано, т.к. не известно кто чем занимается и с какими технологиями работает, чтоб пообсуждать общие проблемы и интересы) Надо бы на бейджах писать теги типа #git. #rabbit, #geo, #php, #c++, #erlang и т.д., чтоб было понятно кто тебе интересен и с кем хочешь пообщаться=) Думаю надо бы эту мысль протолкнуть на следующей организации подобной технологической конференции.

В общем посидели опять же пообщались, новосибирцы попиарали свой CodeFest =)

Утром второго дня вернулся послушать доклад Константина Осипова про их Tarantool в сравнении с redis`ом, запомнил только, что у них более похожая на реляционную организация работа с бд, с несколькими уровнями иерархии. А больше ничего и не запомнил, чем он лучше редиса пропустил и вобще проспал =)

Интересно оказалась послушать товарищей(Андрея Смирнов и Василий Евсиенко) из Skype`а про решардинг редиса на живую, они почитали код редиса и написали хитрый прокси-демон который умеет фильтровать поток репликации редиса, чтоб разбить его на несколько аналогичных потоков и таким образом поделить 1 шард на несколько "на лету". Можно только похлопать им. Вобще решение получилось простое и гениальное) Жаль не опенсорсное)

Потом паралельно шли доклады об Apache Cassandra и pconnet`е от Сергея Аверина из Badoo. Об кассандре опять начали читать мануал и потому я бегал между залами и коридором, то там, то сям ожидал не расскажут ли чего полезного. Про pconnect были комменты в стиле: "php`шнеги впервые узнали о сокетах что-ли =)". Собственно аверин из них себе пользу извлечь умудрился, т.к. оверхед на установление соединения у него был равен оверхеду полученяи данных. Хоят и рассказывал очевидности, но по крайней мере живо и весело, что встречалось мало у кого, за что ему плюс в карму.

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

Сначала Аксенов начал с пересказа архитектуры процессоров x86 и умен зародилась мысль типа : "И ты Брут ?!?" (будешь пересказывать мануал), но он быстро исправился и начал рассказывать о действительно интересных вещах. И на примере показывать, как оптимизировал конкретное приложение в 4 раза по скорости выполнив 8 шагов, где-то убыстрив на 8-15%.

Качество его доклада хорошо отображается таким твиттом "после доклада Аксенова стало стыдно, что пишу на интерпретируемом языке." Вобще наверно один их тех докладов от которых была для меня наибольшая польза =) 

Узнал, что msvc по умолчанию компилирует с какими-то жутко древними флагами совместимости) А gcc не так плох но и за ним надо следить)

Потом опять был обед)

Доклад про openstat меня не впечатлил, даже забыл о чем рассказывали. Опять же доклад про column-orientied бд типа InfoBright для MySql`я вроде был и неплох но не запомнился, т.к. ничего полезного для себя не запомнил, кроме того, что в них чаще всего можно только инсертить, но по некоторым запросам они быстрее оказываются, чем стандартный myisam & innodb.

Петр Зайцев пересказал кучу "What's new" о MariaDb, Drizzle и прочих форках и не форках mysql`я. Что опять же заставляет грустить, лучше случаев из своей консалтерской практики рассказал.

Говорят Комсомольская Правда эпически облажалсь на своем докладе про код в стиле 90х, но сам не слушал, потому рассказать не могу.

Потом послушал Олега Илларионова из вконтакте про Ajax Layout, хоть и не highload, но было просто интересно, как переводили сайт, что делали, почему ифрейм лучше аякс запросов, о том как они заставляют работать кнопку назад, об уведомлениях и прочих штуках, после доклада его обступила толпа человек в 20-30, так что ,наверно, можно считать одним из самых успешных докладчиков.

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

Последнее, что запомнилось был доклад об нестандартном использовании репликации Mysql, как вы возможно догадываетесь ребята написали библиотечку для парсинга row-based репликации mysql`я. Например через нее можно написать какой-нить кеширующий демон, или наоборот чистилку кеша. Штука я считаю вобще полезная хотя пока и не знаю где-бы она мне могла пригодиться.

Итого: 

Еда - отлично. 

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

Докладчики и доклады - на троечку, иностранные докладчики ничего особо нового и интересного не рассказали тоже. Более-менее интересные доклады были, от русско-язычных докладчиков и почти все про эрланг =)

Цена - ужасно высокая для такого мероприятия. 

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

Афтерпати надо добавить определенно, и может добавить мини-секции по конкретным технологиям и интересам.

Конференции и все-все-все =)

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

НО не интересные доклады и темы, хотя и интересные докладчики (из Гугла, Фейсбука, ИСП РАН Клаудеры). Только два доклада показались просто любопытными: все остальное в стиле: ну это я читал в интернете\книжке, или что еще хуже: омг кажется такое уже больше пары тройки лет есть в руби(или больше 20 лет в лиспе) наконец-то додумались и в него добавить) - это толстый намек про новый стандарт си++ .

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

Эпик фейл, что и не говори.

Менеджерские и аджайльные конференции в РАЗЫ веселее, хотя там тоже рассказываю баяны из книжек. По крайней мере я хоть получу удовольствие от шоу =)

В общем забил на полагающееся после мероприятия пиво-пати и просто отправился по своим делам)

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

И по большей части это слова типа : "ну вот там он неплохо выступал, наверно можно позвать" =)

Так вот к чему это я: в общем эра конференции, как мест обмена информацией все больше умирает(Стас Фомин гарантирует это, а на хабре говорят что средняя тема интересна 100 слушателям). Я уже если честно хожу редко ожидая услышать что-то новое, а больше из соображений нетворкинга: повидать старых знакомых\завести новых, узнать кто-там интересный в сообществе появился.

Но конференции для этого слишком громоздки: много организации, довольно внушительная стоимость (15-18к за послушать пересказы книжек и возможность попить пива с теми с кем не факт, что и работать когда-нить буду = где-то тут наебалово "конфуз").

В общем для своей основной цели - не годятся, для вторичной - не удобны. Так зачем вобще их проводить ? Чтобы был повод собраться итшной-тусовочке ? Дык чтоб собраться и побщатсья совместно нужно просто место и желание. Например в том же digital october, в офисе CustIS`а,  Luxoft c удовольствием попиарится, да и думаю ваша компания не откажется от дополнительной известности и возможности рассказать о себе миру.

Вот за что мне в последнее время нравиться DOU, так это тем что там активное коммьюнити, статьи собирают 100-200 комментариев, люди друг-друга знают, проводят регулярные хакатоны и т.д.. И вобще стремятся к образу Silicon Valley c ее meetup`ами и drinkup`ами.

Та жа agile russia худо-бедно собирается на свои встречи, хотя в последнее время с напрягами =) Что кроме аджайлистов никому не интересно узнать, что-то новое от коллег или обмусолить давно мучающие вопросы, познакомиться с коллегами и т.д. ? Кроме аджайлистов нет ни больше ни 1го активного коммьюнити ? Менеджеров, юзабилистов, аналитиков, просто всех кто связан с разработкой по, но почему-то достаточно регулярные встречи проводятся по большей части все еще во время конференций. Даже если они и есть, то почему-то служат тусовочкой "для своих", как будто кто-то там расскажет что-то, что нельзя прочесть в интернетах, и что взорвет вам мозг)

Почему ?
Для меня - загадка, верней - просто причина для недоумения.
Что-то мешает на выходных собраться в кафе\офисе\баре и быть в курсе последних событий и тенденции ?:
Банальная лень ? (Черт и не лень ведь на грабли например наступить на работе, которые кто-то уже мог исправить)
Отсутствие времени ? (Ну у кого реально гтд раскачен до того уровня, что нет свободной пары часов на неделе ?)
Финансовые сложности ? (Пфф, купить пива в баре посидеть - копейки).
Кто-все-эти-люди-и-о-чем-они-говорят ?) Дык ради того и нужно встречаться и узнавать друг-друга.
Мне-не-о-чем-рассказать-всем-этим-крутым-людям ? Неужто ты думаешь, что они способны обрабатывать всю информацию в мире ? Или ты думаешь у них нет личной жизни и бесконечно много времени, и они способны читать и знать все и вся ?

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


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


Всего хорошего и спасибо за рыбу! =)

Остаться в живых.

Прочитал очередную классику научной-фантастики современного менеджмента ит-проектов книгу Стива Макконела "Остаться в живых! Руководство для менеджеров программных продуктов".

Общее впечатление:

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

В рамках последних тенденций ажайла\лина и прочих "гибких" методологий довольно бюрократичная, не PmBOK конечно, но вполне себе увесистая. Что-то вроде PmBOK Light Edition =)

Некоторые из этих бюрократизмов несут довольно зрелое зерно, например интересной показалась идея именно выделенной "change control board", т.е. наличие выделенной команды, которая ответственна за внесение изменении и главное отслеживание их и ведение некоторого перечня, потому как уж очень часто встречается, что почему так сделано никто уже не помнит: "Sad, but true".

Суть книги в двух словах:
Лучше сразу делать процесс, и "наш процесс (tm)".

Как обычно

Как надо

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

И, ВНЕЗАПНО, оказывается, что проект на полезную работы отводиться ровно 0% времени.

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





Что было интересного: 

В книге приводиться чеклист (survival checklist): это возможность оценить по нескольким пунктам насколько высока вероятность успешного завершения проекта, каждый раз, как я считаю на моих работах получается, что лучше бы проект и не начинали или хотя бы 5-% на 50%, но все таки живут они как-то =). Хотя с другой стороны это хороший такой пример: TODO, что надо бы учесть и о чем не забыть. Можно иногда пробегать глазами, чтоб знать чего.

Хотя с другой стороны вопросы типа: "Does the project have detailed, written architecture and design documents?" как-то идет вразрез с теми же ажайл-принципами типа "don't overengineer ahead of time". Довольно неоднозначно это все, но взглянуть все таки стоит.

Пост с ссылкой на чеклист от Максима Дорофеева.

Еще показалась интересной техника defect seeding, как средство проверки качественности тестирования. Из названия ясно, что в разные места намеренно вставляются легко-исправляемые ошибки, и дабы определить сколько всего ошибок в софте.

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


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

Итого:
Как первая книжка про software project management была-бы хороша, но если что-то уже читали более-менее серьезное, то максимум -  пробежать глазами и посмотреть, что же можно применить у себя + выписать чеклист, посчитать вероятность удачи, и посмотреть что же нужно исправить.

P.S. Книжку читал на языке оригинала поэтому цитаты на английском.

Я вижу о чем вы думаете

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

Но замечать за собой и за другими невербальные сигналы типа:

• 1)беспокойства и успокаивающих жестов, 
• 2)поз уверенности и неуверенности, 
• 3)положительного\отрицательного\нейтрального отношения к теме

помогает.

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

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

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

Не хочешь говорить на неприятную тему: мозг на автомате развернет твои ноги по направлению к выходу.

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

Человек сказал тебе что-то неприятное: человек скорчит гримасу, или покажет язык(на детях хорошо заметно, + на тренинге по переговорам была прям такая реальная реакция на одно из моих замечаний, хотя сам человек когда я сказал ему об этом не заметил ее =)).

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

Поэтому важно замечать различия между стандартной реакций, и ее изменением, если человек гладил ногу из-за того, что у него легкий стресс из-за личных проблем, но при вопросе: как там у тебя с задачей\проектом,  он начал гладить ее сильнее - значит все не так уж и хорошо, и надо бы этот вопрос раскрыть =) Вобще по возможности не стоит давать оценочные суждения типа: врет, скрывает, что-то недоговаривает.
Лучше судить по точным и простым реакциям: "о вот этот вопрос его беспокоит, а этот неприятен. Надо бы выяснить, что в нем такого неприятного и беспокоящего. А как там дела с проектом Х: как с командой, со сроками и т.д. ?"
А то может оказаться, что беcпокоиться он по поводу того, что опаздывает на встречу по этому проекту, а вы тут с выяснениями пристали.

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

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

Спасибо за чтение и удачного дня.

P.S. По результатам тренинга("Искусство выступать и убеждать" Игоря Незобиватько из Ораторики) по выступления нарисовал майнд-мап, но пост на эту тему делать не буду, т.к. мне интереснее тренироваться и  выступать публично, посему если майнд-мап вызовет вопросы и интерес напишите мне, и я постараюсь выступить перед вами =)

Переговоры, которые работают.

Не далее, как неделю назад в рамках подготовки к тренингу по переговорам сгрыз плитку гранита науки о переговорах. А точнее Стюарта Даймонда "Переговоры, которые работают. 12 стратегий, которые помогут получить вам больше в любой ситуации." По английски книга называется "Getting More", что по-моему звучит лучше и передает смысл книги понятнее.

Если вы в первый раз слышите об авторе - ничего страшного. Собственно до прочтения я тоже не знал, кто это и откуда он взялся) 


Небольшая историческая справка: Стюарт Даймонд(Stuart Diamond) – профессор Уортонской школы бизнеса, генеральный директор Four Star Airlines, один из самых востребованных специалистов по переговорам в США.


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

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

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

Когда у вас есть - ЦЕЛЬ, то сразу становиться понятно, что ведет вас к ней, а что есть трата нервов, времени и сил. Какой смысл злиться на собеседника, если злоба не приведет меня к желаемому результату? Какой смысл ругаться с нерасторопным служащим, если в итоге он станет медлить вам назло? Это не приведет к вашей цели.

Да и почему пустопорожние разговоры c кем-то вроде вас должны заставить собеседника стремиться сорваться сделать то, что надо ВАМ? Чтобы человек, что-то сделал надо, чтобы это было выгодно ЕМУ, после исполнения он должен почувствовать себя лучше: избежавшим дурной ситуации или честно выполнившим свой долг, наконец просто ответившим на любезность и добрые слова.

Дело  в НИХ, поставьте себя на их место: поймите, что они любят, кого уважают, кто способен помочь им добиться своих целей. Чтобы ВЫ добились результата, люди должны ЗАХОТЕТЬ помочь вам. И следует действовать так, чтоб каждый ваш шаг усиливал их желание и их выгоду от помощи вам.

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

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

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

Ведь наврядли начальник откажет вам в такой мелочи, как например, поднять зп на тысячу рублей, уж на тысячу то вы заслужили, ну и тысяча это ведь курам на смех, бумажной волокиты только, лучше наверно на 2-3.
Да и что-то давно не поднимали, чтоб я тебя через месяц опять с этой херней не донимал можно наверно сразу на 6-7 поднять? Да и вообще, блин, зачем дробными поднимать? Округлим до 10к и все?

Ну, вы уловили идею?

Обменяю свое без ценное
на ваше ценное =)

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

Что волнует данного человека? Духовное или материальное, что-то имеющее к вашим переговорам или что-то не имеющее? Работа в выходные, когда все горит и паника, может стоить обмена на пару дополнительных дней отпуска?
Может ваша услуга "отвезти тещу собеседника до аэропорта" будет стоить гораздо больше этих
сотен тысяч денег? Ведь деньги еще можно заработать, а любовь тещи  - только потерять =)

Увеличьте пирог для всех, добавьте что-то, что ваш собеседник оценит, большей своей доли. Вин-вин в чистом виде.

Вот тут у вас написано,
 что клиент всегда прав

Люди, да и компании в целом любят ставить перед собой цели и идеалы, они воздвигают для себя явные и неявные стандарты. У них есть мораль и кодекс чести. На их основе они принимают решения, выносят вердикты, и зачастую используют их, как прецеденты и законы. Эти стандарты можно использовать, чтоб добиться большего(сиречь название книги). Если у стандартов есть исключения и правила - тем лучше, значит этими исключения можете воспользоваться и вы, ведь это справедливо, ну или вы по крайней меру узнаете, кем надо быть чтоб попасть под исключение =)
Должны ли невинные люди страдать из-за ошибки компании? Клиент всегда прав? Вот ведь у вас написано, что вы работаете ради клиентов а не ради денег! Ваша миссия - "продвигать услуги на российском рынке", так давайте вы сделаете для меня это а я расскажу о вашей замечательной компании своим друзьям и тем продвину ваши услуги! Вы тут обещаете высокий уровень обслуживания, а как же - "вот это", как же вы тока продемонстрируете мне свой высокий уровень обслуживания?

Последняя фраза выглядит вполне себя так манипулятивно, не так ли? Говоря такое и нагло ухмыляясь в чье-то лицо вполне можно и в глаз схлопотать =) Одно дело искренне, по-деловому и конструктивно предлагать решение проблемы, и другое нагло и с визгом требовать сатисфакции. Если вы искренне так не думаете - то не стоит применять такие приемы.

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

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

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

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

Ищем проблемы.

И решаем их.

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

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




Ну и наконец, переговоры - такое же ответственное дело, как и любая другая задача. Готовьтесь к ним заранее и имейте СПИСОК стратегий, которые можно применить.
Применяйте Список на практике:
узнайте о другой стороне, чем она увлекается и чем интересуется, каких стандартов она поддерживается.
Что она ценит высоко, а что не очень?
Эмоционален ли этот человек? Как у него прошел день?
Какие цели они ставят перед собой?
А какие цели ставите вы? Вы сейчас обсуждаете именно, то что ведет к вашей цели? Или перешли на эмоции?
Идите ли вы на контакт или отбрыкиваетесь от собеседника?
Достаточно ли четко другая сторона понимаем ваши цели, и верит ли она в вашу искренность?
Каким образом вы можете убедиться, что другая сторона взяла на себя обязательства? Например, в многих странах Ближнего Востока подписанный договор ничего не значит, если он не был скреплен рукопожатием.


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

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

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

Верьте мне! =)

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

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

Спасибо за чтение и удачных вам переговоров и побольше-побольше!)