Русский
Русский
English
Статистика
Реклама

Коммуникация

Что такое алгоритм?? Part three and a quarter. Язык

10.06.2021 08:18:29 | Автор: admin

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


.

Title


Задача


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


Это Слово. Это Смысл. Это сложности перевода. Наконец, это разбор появления коммуникации.


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


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


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


Потому что любое обсуждение этой темы полезно. И позволяет ускорить движение к цели.


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


И давайте обсуждать вместе. Ведь это "жжж" рядом с заголовком "Что такое алгоритм ?!" неспроста.


А зачем тебе жужжать, если ты не пчела? По-моему, так

А зачем на свете пчелы? Для того, чтобы делать мёд.

Жжж


И, конечно, "алгоритмический" мёд не очень интересен сказочному медвежонку, но, возможно, он станет полезен кому-то другому.


Слово


Пора уже начать. И в этот раз совсем нет причин изменять привычному для этой серии статей формату. Мы опять будем "терзать" общепринятые термины из Википедии. На нашем пути термин "Слово":


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

Как ни странно, но представленное определение весьма "крепкое", хоть пока и не формальное. А для выполнения его формализации необходима лишь малость. Нужно:


  • формализовать алгоритм именования предметов, взаимодействий и их качеств (характеристик);
  • понять и определить, что есть "мнимое и отвлеченное понятие", и затем формализовать алгоритм создания этой абстракции в человеческом воображении.

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


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


мультфильм головоломка


Коммуникация


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


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


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


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


Итак, есть мостик от алгоритмов коллективного выживания к алгоритмам "именования предметов". Почему здесь использовано слово "алгоритмам" во множественном числе? Это связано с разной природой "именуемых" явлений. И совсем немного этому посвящена пара статей "Математика" и "Физика". Там намеренно отдельно в каждой статье рассмотрены особенности "переноса" в пространство модели для "стада коров" и для "падения яблока".


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


Именование трансляцией


Абстракция


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


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


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


Итак, на основе рассмотренного ранее мы с Вами уже можем еще неформально, но в формальных терминах (отмеченных курсивом) теоретической части этой работы, сформулировать своё определение "Слова":


Слово это объект в пространстве языковой алгоритмической системы, который:
  • формируется с использованием модельной трансляции (например, человеком) комплементарным сопоставлением с объектом или алгоритмом из прикладной области;
  • создается как продукт работы алгоритмов в языковом пространстве, необходимый для алгоритмов, исполняемых только внутри языкового пространства, и не переносимый в прикладную область.

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


Копирование поведения


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


Смысл


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


Question of life


$\begin{gathered}42 \\ = \\ (-80538738812075974)^3 + \\ 80435758145817515^3 + \\ 12602123297335631^3\end{gathered}$



И если в текущий момент статьи сделать паузу и обратить внимание на предыдущее предложение, а еще сразу на все статьи серии. То можно отметить, что цель всего этого собрания слов в статьях только одна объяснить особый смысл слова "Алгоритм". А способ это осуществить используется такой же, как и для всех иных слов, с которыми сталкивается человек. Начиная с первого слова "мама" и заканчивая "большим адронным коллайдером" (да, конечно, тут 3 слова, но ведь смысл один?). И этот способ связывания слова со смыслом спрятан достаточно глубоко в устройстве человеческого мышления, а вернее в приемах используемых в процессе синтеза алгоритмов его поведения.


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


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


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


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


Главный смысл "Слова" содержится в полезных алгоритмах, которые используют это слово! Да, смысл совсем не внутри фонем, букв, слогов "слова" и не в способах именовать объекты окружающего пространства. Этот смысл "снаружи"! Он в использовании. Он в алгоритмах!!!


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


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


Алиса и Аня


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


Перевод


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


Думаю сейчас опять стоит обратиться к Википедии. И разобрать следующий существующий на её страницах термин слово "Перевод":


Перевод деятельность по интерпретации смысла текста на одном языке (исходном языке) и созданию нового эквивалентного ему текста на другом языке (переводящем языке).

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


О, опять целый рой вопросов. Как бы уложиться с ответами в последнем разделе приемлемого объема. Хорошо, что у нас уже есть опора для формирования ответов. И здесь нам очень поможет разбиение на "классифицирующий смысл" и "смысл использования".


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


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


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


Кузинатра


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


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


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


Выводы


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


Мы познакомились с термином "Слово" и нашли в нём два смысла, один из которых будет весьма полезным в доработке существующих систем перевода текстов на естественных языках.


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


Намечен эволюционный переход от естественных языков к языкам программирования.


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


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


Спасибо Вам за внимание.


Отзывы


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


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


Ссылки


Подробнее..

Как продать технические задачи бизнесу

23.04.2021 12:19:27 | Автор: admin

Поддерживать высокое техническое качество кода прямая обязанность техлида. Но чтобы этого добиться, зачастую приходится доказывать начальству и заказчикам необходимость вкладывать в улучшение кода силы и время. Как сделать это, не стаптывая в бесконечных согласованиях железные башмаки и не стирая язык до мозолей? Об этом в своем докладе на конференции TechLead Conf 2020 Online рассказал консультант Better Life Company Алексей Дерюшкин.

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

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

Проблемы Алексея выглядели так:

  • Бизнесу совершенно неинтересно, что находится под капотом и как сделать код лучше;

  • Бизнес не разбирается в системе и не хочет это делать;

  • Сам техлид не умеет вести переговоры;

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

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

Из-за этого непонимания техлид не может продать идею. К тому же не все умеют уговаривать людей и просто продавать что бы то ни было. Недопонимание накапливается, и в итоге : Блин, да что с ними спорить? Я ему рассказываю, как надо сделать, а он ничего не понимает. Не буду этим заниматься в следующий раз!

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

Чем продажа идеи отличается от программирования?

Спойлер: ничем!

Есть три ключевые вещи, которые обязательно нужно сделать для того, чтобы успешно продать какую-то идею:

  1. Подготовиться заранее. Если вы не обучались продавать свои идеи, то выйти и свободно вести разговор в нужном русле может быть сложно.

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

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

Пример неудачной продажи

Техлид приходит к владельцу продукта:

  • Привет! Я хочу добавить в этот спринт задачу по рефакторингу.

  • Привет! Нет, в этот спринт мы должны выпустить новую фичу, мы уже обещали.

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

  • Ну, делайте сразу нормально, кто ж мешает?

Это результат неподготовленного диалога.

Давайте разберем ошибки типичного диалога техлида с бизнесом:

  • Птичий язык: владельцу продукта непонятно, о чем мы говорим;

  • Готовые решения. Человек, которому мы продаем идею, не участвовал в ее разработке. Он не знает, почему эта идея ему нужна и как она связана с тем, чего он хочет добиться;

  • Потребность убедить в своей правоте, а не помочь решить проблему бизнеса.

Итог закономерен: бизнес чувствует себя дураком, искренне не понимая, зачем нужно делать техдолг, когда можно сделать фичу.

Система продаж Джордана Белфорта

Есть замечательная цитата:

В фильме Волк с Уолл-стрит с Леонардо ДиКаприо прототипом главного персонажа является Джордан Белфорт один из самых известных продавцов и автор системы продаж.

На чем основывается его система? Джордан утверждает, что у вас купят идею (а на самом деле купят что угодно: телефон, автомобиль и т.д.), если есть 100% уверенность:

  • В идее (продукте, предложении);

  • В вас, как эксперте;

  • В людях, которых вы представляете.

Рассмотрим бытовой пример: вам продают автомобиль.

  • Идея 71%

Вы не совсем уверены, что автомобиль нужен вам как продукт. Но все же вам нужно ездить из пункта А в пункт В (на дачу, возить ребенка в школу).

  • Эксперт 83%

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

  • Команда 78%

Вы также достаточно уверены в том, кого представляет продавец. Это может быть известная компания по продаже автомобилей или определенная марка. Например, вы уверены в том, что ес ли купите Mercedes, он не развалится в первый день, и не уверены в том же самом с АвтоВАЗом.

Если во всех трех пунктах ваша уверенность 100% или близко, то скорее всего, автомобиль вы купите.

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

Вернемся к примеру с автомобилем, и рассмотрим вариант, когда вы не купили машину:

  • Идея 0%

  • Эксперт 100%

  • Команда 100%

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

Если вы уверены, что автомобиль вам нужен, но при этом вы не доверяете продавцу вам кажется, что он хочет вас надуть или впарить 100500 опций, то конкретно у этого человека вы не купите:

  • Идея 100%

  • Эксперт 0%

  • Команда 100%

В случае, когда вы не хотите связываться с АвтоВАЗом, и LADA Granta не ваша мечта, будет так:

  • Идея 100%

  • Эксперт 100%

  • Команда 0%

То есть если даже один параметр будет не 100%, а 30-40% и ниже, вы не убедите человека купить автомобиль. А на месте техлида не продадите идею сделать тесты, что-то автоматизировать или провести рефакторинг.

Важный момент по поводу 100 баллов из 100. Вы можете только предполагать, каковы цифры на самом деле. Странно было бы на переговорах говорить человеку: А ну, скажи мне: от 0 до 100, насколько ты во мне уверен?. Это просто метафора, а не цифры, которые можно использовать в разговоре.

Как добиться уверенности на 100\100\100?

Идти по алгоритму.

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

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

Алгоритм продажи чего угодно, в том числе идей

Первые четыре секунды

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

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

Кратко изложите, зачем пришли (позвонили, назначили встречу). Человек, скорее всего, чем-то занят, это элементарная вежливость.

Спросите, есть ли время на обсуждение? Это важно, особенно, если разговор спонтанный. Например, вы увидели в коридоре человека, с которым давно хотели поговорить. Он должен дать прямое согласие на то, чтобы пообщаться с вами.

Раппорт

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

Отсутствие раппорта очень хорошо описывает картинка:

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

Сбор информации

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

Давайте посмотрим на три пункта:

  • Боли ярко окрашенные негативные эмоции;

  • Выгоды позитив;

  • Цели и задачи более нейтральные вещи.

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

Основная презентация и предложение о покупке

Когда мы рассказываем о своей идее, обязательно нужно говорить на языке того человека, с кем мы общаемся. То есть на языке бизнес-целей!

Строим презентацию по схеме:

  • Как ваша идея поможет собеседнику?

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

  • Визуализируем ужасное будущее;

  • Визуализируем хорошее будущее;

  • Если это нужно, даем МИНИМУМ технических деталей;

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

  • Называем цену.

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

Очень хорошая фраза, которая отдает мячик вашему собеседнику после презентации:

Мне кажется, это хорошая идея. Что скажешь?

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

Перенаправление на рост уверенности.

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

  • Спросите, что смущает, и развейте страх

Если у вас не купили, значит, нет уверенности. Надо выяснить, где провал, почему 50% вместо 100%. И постараться это починить. Возможно, собеседник скажет напрямую:

  • Я не уверен, что это поможет.

Об идее, скорее всего, можно говорить прямо. Но вряд ли человек скажет:

  • Я тебе не доверяю, как специалисту.

Или:

  • Мне кажется, твоя команда не справится.

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

Снижение порога действия

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

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

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

  • Просто кивни, мы все сделаем сами.

  • Тебе ничего не надо будет делать.

  • Мы уже попробовали, и вот результат...

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

Усиление боли

Это визуализация страшного будущего, в котором ваш собеседник не согласился на вашу идею:

  • Если ничего не поменяется, то...

  • Знаешь ли ты, что будем, если мы этого не сделаем?

  • Через год станет

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

Закрытие сделки

Это опять передача мяча собеседнику:

  • Что дальше?

  • Ну что, попробуем?

  • Ты согласен, что...?

Это прямые вопросы, которые вы задаете собеседнику: Ну, как? Берем работу в следующий спринт? Ставим в план на следующий месяц?. Но эти вопросы часто просто забывают задать. Мы вроде бы обсудили идею и просто ждем, когда человек сам скажет: Ладно, давай. Я буду делать то-то и то-то.

Нет, пожалуйста, возьмите инициативу на себя и задайте вопрос: Ну как, работаем дальше?.

Пример

В 2015 году в одной из команд Алексей работал как техлид и на этапе подготовки он узнал о том, что сроки выхода в продакшн жестко зафиксированы, а в SLA на починку ошибки в продакшн выделено всего три дня.

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

Диалог был примерно такой:

  • Привет! Я хочу обсудить одну техническую задачу, которая может ускорить время разработки задач и починки ошибок. Есть 10 минут, чтобы обсудить сейчас?

  • Давай.

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

Дальше идет презентация:

Смотри, сейчас у нас нет автотестов, и каждую фичу перед выпуском мы тестируем руками, ЭТО ДОЛГО. Я с ребятами УЖЕ ПОСЧИТАЛ, что если мы закроем 15% функционала тестами, то разработка каждой новой фичи УСКОРИТСЯ НА 2 ДНЯ. Благодаря этому мы сможем сделать на 10 фич больше до дедлайна. Мы все сделаем сами, надо просто взять в этот и следующий спринты задачи по разработке тестов. За этот месяц мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. А еще это поможет быстрее чинить баги.

Что мы здесь видим? Во-первых, в презентации были указаны конкретные цифры. 15% функционала, 2 дня и 10 фич.

Во-вторых, был минимум технических деталей, а конкретно одна: 15% функционала надо закрыть. Цифра на самом деле не важна это может быть и 10%. Владельцу продукта важнее, что разработка новой фичи ускорится, или что баги будут чиниться быстрее.

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

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

В оригинале презентация была долгой, встреча на час. И одна из фраз, которая там прозвучала:

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

  • Что скажешь?

Это пример, как можно по такому алгоритму проводить продажи идей.

Полезные фишки

Есть полезные фишки, которые помогут в любом диалоге:

  • НО наоборот;

В предыдущем примере как раз используется эта фишка: мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. Обычно мы говорим: Я сделал что-то хорошее, НО будет вот это и вот это плохо. То есть сначала обговариваем позитивные моменты, а потом идут НО и неприятные вещи. Поменяйте их местами: если есть что-то неприятное, сначала расскажите о нем, а потом о хорошем: Сейчас сделаем на 20% меньше фич, НО потом мы будем эти фичи печь как пирожки.

  • Потому что;

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

  • Визуализация;

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

  • Двойная петля;

Если вы видите, что собеседник сомневается (сначала у него есть один аргумент против, потом появляется другой, третий), скажите ему прямо: Мне кажется, что ты не уверен в идее, которую я принес. Расскажи, почему?. Так он попадает в двойную петлю: либо говорит: Нет-нет, я уверен, и начинает сам себе продавать уверенность, либо говорит: Да, я не уверен, и тогда дает вам аргументы, с которыми вы сможете работать.

  • Прямолинейность.

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

Подводя итог

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

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

Кроме того, вы должны добиваться 100% уверенности по трем пунктам: в продукте, который продаете, в вас, как эксперте, и в людях, кого представляете.

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

TechLead Conf 2021 пройдет 30 июня 2021и 1 июля 2021 в московской Radisson Slavyanskaya. Расписание можно посмотреть здесь.

Билеты на конференцию вы можете приобрести уже сейчас. Спешите: 1 мая цена станет выше!

Подробнее..

Групповые чаты не работают как мы сделали форум внутри таск-трекера

30.04.2021 10:21:30 | Автор: admin

Когда-то форум локального интернет-провайдера был площадкой для знакомств, источником контента и местом, где вы встречались с товарищами по гильдии в World of Warcraft. Но могут ли механики форумного общения быть полезными в эпоху чатов?

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

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

Как люди читают форумы

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

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

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

Часто такие участники попадают на форум из гугла. То есть даже внутренним поиском и рубриками они не пользуются.

Актуальные типы форумов
  • Q&A-форумы. Сайты с механикой вопрос-ответ:StackOverflow, форумы юридической поддержки и медицинских консультаций. Да даже ОтветыMail.ruподходят, чего уж там.

  • Старые форумы-комьюнити. Эти сообщества возникли ещё до распространения Facebook, а потом не стали переезжать. Такие, например,официальные форумы WoW.

  • Форумы техподдержки. Каждый тред это тикет, который специалист должен закрыть.

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

Высокий порог входа

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

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

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

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

Почему групповые чаты не работают

Попробуйте собрать 10 друзей в одной переписке. Возникнут очевидные неудобства:

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

  • Не хватает времени, чтобы следить за обсуждением. Некоторые участники перестают понимать, что происходит.

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

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

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

Подкастерский чат, в который я редко захожу. Понятия не имею, что там сейчас обсуждаетсяПодкастерский чат, в который я редко захожу. Понятия не имею, что там сейчас обсуждается

Крупные игроки вродеDiscordиSlackпонимают проблему, поэтому разводят общение по каналам, привязанным к темам или проектам. Но по факту каналы это тоже групповые чаты, с ними возникают такие же проблемы. Если канал популярный, он быстро превращается в помойку.

Чат vs форум

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

Нужно обсудить четыре вопроса: маршрут, время отъезда, список припасов, а также сколько скидываться на покупки и бензин.

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

Если задавать вопросы по одному: анализировать ответы станет проще, но общение затянется. Этапы идут в чёткой последовательности нельзя зайти и разом ответить на всё, что нужно.

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

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

Разговор идёт параллельно по нескольким темам, но соблюдается структура. Можно быстро проверить обновления и ответить на все вопросы разомРазговор идёт параллельно по нескольким темам, но соблюдается структура. Можно быстро проверить обновления и ответить на все вопросы разом

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

Форум добавляет ещё один структурный слой. Чаты это треды, а над ними мы делаем надстройку в виде разделов. Благодаря этому следить за обсуждением становится легче.

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

  • Общение на мероприятии. У каждого лектора своя колонка, темы можно обсуждать в карточках.

  • База знаний.Разные колонки для книг, видео и статей. Одна карточка одна единица контента вместе с обсуждением.

  • Организационные вопросы. Например, форум с успехом может заменить домовой чат.

Как мы сделали форум внутри таск-трекера

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

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

  • Интерфейс приложения должен быть ориентирован на чат. В YouGile так и есть, общение по задачам основная идея нашего сервиса.

  • Карточка должна показывать, что в треде есть новое сообщение. Иначе будет неудобно их проверять.

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

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

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

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

За неделю получили более 300 комментариев, идей для улучшений хватит на много спринтов.

Качество общения выросло: на форуме клиенты пишут подробнее, чем в телеграмеКачество общения выросло: на форуме клиенты пишут подробнее, чем в телеграме

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

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

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

Пообщаться на форуме

Кстати, вы можете создать свою доску-форум это бесплатно, без ограничений. Если захотите организовать работу команды вYouGile, то до 10 человек все функции тоже доступны бесплатно (это навсегда).

Подробнее..

Рожден быть киборгом Мастер-класс от эксперта с инвалидностью

19.12.2020 22:21:31 | Автор: admin

Уникальный мастер-класс пройдёт 21 декабря в рамках III Ежегодного Слёта участников рынка реабилитационной индустрии. Каждый желающий сможет научиться основам взаимодействия с людьми, имеющими ограничения здоровья или мобильности. Занятие проведут ведущие российские эксперты в сфере инклюзивных коммуникаций.

Регистрация на мероприятие уже открыта: https://pazl.academy/ru-RU/content/registration

Мастер-класс проведёт Илья Морковский, блогер, инклюзивный тренер и кибер-амбассадор российской компании Моторика.


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

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

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

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

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

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

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

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

Онлайн-формат позволит посетить мастер-класс всем желающим. Ссылка на трансляцию придет накануне мероприятия на почту, указанную при регистрации: https://pazl.academy/ru-RU/content/registration

Подробнее..

Business English Как грамотно рассказать о своей компании формула

29.03.2021 12:16:08 | Автор: admin

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


  1. 2-3 слова, описывающие основную деятельность компании

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

Например: international payment provider, consulting agency


2. 2-3 слова, описывающие основную деятельность компании + свои цели

Подходит для конференций и прочих networking ивентов, где время ограничено, новых лиц много, а вы ищете конкретных людей.

Например: My company is a medicine supplier and I am looking for a local partner in Indonesia.


3. Развернутое описание компании

Подходит для знакомств по переписке (LinkedIn, холодные письма), а также запланированных встреч, где у вас есть время пообщаться.

Развернутое описание компании должно отвечать на 2 вопроса:

  • Чем занимается ваша организация?

  • Какие у вас преимущества по сравнению с конкурентами?

Существует эффективная формула позиционирования компании, с помощью которой можно красиво ответить на эти вопросы. Вот она:

1. For [target customer]

Кто является потенциальным клиентом

2. who [statement of the need or opportunity]

Какая у клиентов есть потребность / боль

3.the [product name]

Название вашего продукта

4. is a [product category]

Категория вашего продукта

5. that [statement of key benefit].

Преимущества вашего продукта

6. Unlike [primary competitive alternative]

Название конкурента или его продукта

7. our product [statement of primary differentiator].

Чем отличаетесь от конкурентов

Рассмотрим на примере вымышленной компании, которая производит софт для создания музыки:

1. For [target customer]

For amateur and professional composers

2. who [statement of the need or opportunity]

who need a powerful tool to turn their ideas into real sounds

3.the [product name]

Music-Making Station

4. is a [product category]

is a software designated to create music

5. that [statement of key benefit].

which will let you create your first track during the first visit.

6. Unlike [primary competitive alternative]

Unlike other DAWs

7. our product [statement of primary differentiator].

Music-Making Station is genuinely intuitive and contains all necessary instruments and plugins ensuring the magic is not interrupted by any need.

A так я рассказываю о своем телеграм-канале Business English по этой формуле:

1. For [target customer]

For people working with foreign partners

2. who [statement of the need or opportunity]

who feel that they lack knowledge of specific industry terms

3.the [product name]

Business English

4. is a [product category]

is a linguistic Telegram channel

5. that [statement of key benefit].

that serves as a source of useful phrases and best practice that help to perform more effectively.

6. Unlike [primary competitive alternative]

Unlike traditional methods of learning Business English

7. our product [statement of primary differentiator].

this channel contains only up-to-date info used in everyday international affairs.

Пишите в комментариях, у кого что получается, и при необходимости я помогу с формулировками на английском.

Подробнее..

Иной подход к коммуникации удаленных команд

19.04.2021 20:16:49 | Автор: admin

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

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

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

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

Toolkit больше не нужен

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

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

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

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

Живой пример

Frontend-разработчик Павел пришёл в новый коллектив. В прошлой команде дизайнер рисовал интерфейсы в Sketch (но у паши Винда и он использовал Lunacy), правки доносил через Google Docs, а бизнес логику показывал через Zoom.

А в новой команде используют Figma и Miro. Часть бизнес-логики показывают, через кликабельный прототип. Правки присылают в Телеграм, Slack, либо ставят в задачи в JIRA (но переписка как правило ведётся в мессенджерах).

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

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

Обзор возможностей

Конкретика

Наш сервис решает ваши задачи конкретным способом, поэтому 1 раз изучив, можно использовать эти знания в любой команде. Тем более, что сервис будет интуитивно понятен всем, кто работал с PowerPoint, Miro и Figma.

Интерфейс модуля CaseTrackerИнтерфейс модуля CaseTracker

Накапливаемый опыт

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

А при стандартном подходе всё теряется, разбросано по мессенджерам, таск-трекерам, доскам, каталогам, документам и прочим местам хранения данных.

Всё в одном месте

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

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

Бизнес-логику теперь проще донести

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

Как водится, это видео полетит в мессенджер и там же будет по нему переписка. Либо в JIRA, в виде задачи, но опять же, часть вопросов будет в комментариях к задаче, а часть в переписке в мессенджерах или ещё хуже - при созвоне (половина забудется). И потом концов не соберёшь.

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

Обсуждения с командой

Если всё же есть время созвониться, то можно создать митинг-комнату, в которую в любой момент может зайти кто-то из команды (если роль позволяет). Для того, кто не успел, коллеги сделают запись. Эту запись можно так же комментировать и редактировать, как описано выше.

Итог

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

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

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

Для первой тысячи мы откроем premium-доступ на целый год бесплатно - после запуска MVP.

Для связи со мной Телеграм. Подробнее о сервисе в моём инстаграм.

Подробнее..

Из песочницы Хочешь, чтобы тебе поставили корректную дизайн-задачу? Помоги продакту ее поставить

20.06.2020 22:18:04 | Автор: admin
Однажды в деревне мой дядя Слава спросил, чем я занимаюсь. Большой, мол, уже, 25 лет. Должен же чем-то заниматься. Я ответил, что работаю в Москве дизайнером мобильных приложений. Он кивнул и помолчал с полминуты. Потом переспросил: Так это значит в телефоне там все рисуешь? Да, говорю, чтобы не распространяться. Он достает из кармана кнопочную Nokia и протягивает ее мне мол, давай, показывай, что ты из этого нарисовал. Вот эту иконку сообщения или ту, с телефонным справочником?

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

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

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

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

Первый этап. Пользователь


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

Спросите у продакта:

  1. Как пользователь решает эту задачу сейчас?
  2. Какой результат для пользователя мы хотим получить?

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

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

Второй этап. Бизнес


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

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

Спросите у продакта:

  1. Давай представим, что все сработало идеально. Чего мы тогда достигли? Как это отразилось на бизнесе?
  2. Сколько это в цифрах?

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

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

Третий этап. Что происходит с продуктом?


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

Но чаще всего ответы ближе, чем кажутся у продакта. Спросите его, и он сам всё расскажет:

  1. Кто наши конкуренты?
  2. Где можно посмотреть продуктовую аналитику? Где можно взять события метрики?
  3. Проводились ли какие-то качественные или количественные исследования? Где их можно посмотреть?

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

Четвертый этап. Сроки


Уточните, сколько времени у вас есть на поиск решения, чтобы спланировать работу.

Спросите у продакта:

  1. Когда хотим в продакшен?
  2. Когда должен быть готов дизайн?
  3. Насколько это жёсткие сроки? Можно ли их двигать?

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

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

Пятый этап. Технические особенности


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

Спросите у продакта:

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

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

Контакты


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

Спросите у продакта:

  1. У кого можно узнать специфику продукта? Его продуктовые особенности? Особенности системы?
  2. Как достучаться до этих людей? Почта/телеграм/вотсап?
  3. С кем внутри команды согласовывать драфты дизайна?
  4. Как лучше согласовывать решение? Встреча? Письмо? Другое?

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

Пользователь


  1. Как пользователь решает задачу сейчас?
  2. Какой результат мы хотим получить для пользователя?

Продукт


  1. Чего мы хотим достичь?
  2. Сколько это в цифрах?
  3. Кто наши конкуренты?
  4. Где можно посмотреть продуктовую аналитику? Где можно взять события?
  5. Проводились ли какие то качественные или количественные исследования? Где их можно посмотреть?

Сроки


  1. Когда хотим в прод?
  2. Когда дизайн должен быть готов?
  3. Сроки жёсткие? Есть ли возможность их двигать?

Технические ограничения


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

Коммуникация


  1. У кого можно узнать специфику продукта? Его продуктовые особенности? Особенности системы?
  2. Как достучаться до этих людей? Почта/телеграм/вотсап?
  3. С кем внутри команды согласовывать драфты дизайна?
  4. Как лучше согласовывать решение? Встреча? Письмо? Другое?
Подробнее..

Брайан Фитцпатрик, Бен Коллинз-Сассмэн Team Geek идеальная IT-компания смысл и законы командной работы

10.12.2020 10:23:48 | Автор: admin


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

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

Целевую аудиторию своего труда Фитцпатрик и Коллинз-Сассмэн определяют так: рядовые разработчики ПО, которые работают в составе команды, хотят создавать качественные продукты и не возражают против карьерного роста. Цели научить читателя управлять людьми они не ставили, хотя многие выкладки могу оказаться полезными и для технических лидеров.

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

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

Командный вид спорта


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

В наши дни разработка командный вид спорта. Базовой рабочей единицей является команда программистов.

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

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

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

Создайте, пожалуйста, возможность скрытия определенных ветвей кода в Subversion на Google Code.

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

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

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

С другой стороны, в программистах особенно громко говорит честолюбие: кому не хочется стать следующим Линусом Торвальдсом или Ричардом Столлмэном? Если не делиться идеей и трудностями в процессе, то по завершению не придётся делиться и славой.

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

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

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

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

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

Три кита командной работы


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

По убеждению Фитцпатрик и Коллинз-Сассмэн, продуктивная и здоровая атмосфера в команде складывается при наличии трёх составляющих:

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

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



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

Дискуссии и споры

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

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

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

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

Критика

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

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

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



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

Авторы советуют придерживаться следующих правил при комментировании чужого кода:

  • Говорить строго о коде, не отвлекаясь на привычки и характер его автора;
  • Не впадать в категоричный тон предлагать и советовать вместо того, чтобы требовать;
  • Избегать оценочных, обвинительных реплик (Ты наделал ошибок в, У тебя какая-то путаница с). Вообще, вместо реплик с ты безопаснее говорить от себя или обезличенными конструкциями (Мне непонятна логика, Здесь не хватает).

Разборы полётов

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

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

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

Что можно сделать: Конечно, многое в отношении людей к ошибкам определяется тем, какой посыл исходит сверху. Тем не менее, от себя вы можете привнести правильный настрой. Не бойтесь подробно и публично анализировать собственные промахи, а говоря о чужих делайте упор на конструктивную сторону. Если вам придётся солировать в post-mortem-е, помните: ваша цель не покаяться, а дать компании максимум полезной информации.

Хорошо составленные результаты вскрытия должны содержать в себе следующее:

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

Рокировки

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

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

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

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

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

Английский язык выбери меня, птица счастья

26.05.2021 12:10:08 | Автор: admin

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

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

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

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

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

  3. Подрядчик должен хорошо ориентироваться в современных учебниках* английского. Лучше, если таким хорошо ориентированным будет преподаватель, а не менеджер. Менеджер - это продажник, он может быть любым, учить вас будет не он. Задайте вопрос преподавателю, пусть он назовет хотя бы несколько учебников, по которым он работал или работает. Есть издательства, за ними стоят научные институты, которые разрабатывают учебные программы, к которым пишутся учебники. В штате научных институтов работают лингвисты, нейрофизиологи, нейролингвисты, методисты, теоретики и практики, это очень много спецов. Люди тратят годы, чтобы написать учебник. У каждого учебника есть концепция, а любой учебный комплекс включает в себя мануал для учителя. У разных учебников разные концепции. Об этом хороший преподаватель должен знать, даже если он работает по авторской методике. Скажем так, тем более, если он работает по авторской.

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

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

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

* Например: English File, Outcomes, Upstream, Empower, Серия In use

** Можно услышать названия (например, Lexical grammar или The book of pronunciation), а лучше имена (скажем, Скривенер, Андерхилл, Кристал, Селиван; первый - это главный у преподов английского, его нельзя не знать)

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

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

Бонус-трек. Если после тестирования вам покажется, что вы лучше, сильнее и быстрее того уровня владения языком, который вам определил преподаватель, то хороший препод будет с вами спорить. Скорее всего потому, что при определении уровня владения языком он руководствуется CEFR ( уровни владения иностранными языками, прописанными Советом Европы). Спросите у преподавателя, что это за уровни. Знающий препод сможет вам показать, в чем вы не правы, на то он и профи. У нормальных профессионалов всегда есть ответы, а если их нет сразу, то профи никогда не постесняется сказать, что ему нужно время подумать и поискать ответ.

Подробнее..

Английский только не по учебнику

20.05.2021 12:07:50 | Автор: admin

Английский не по учебнику - клиентский запрос последних лет, который быстро превратился в главное УТП языковых школ и онлайн-платформ, а заодно - в выгодную лазейку для создателей так называемых авторских методик.

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

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

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

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

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

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

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

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

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

  2. Продукты инфоцыган: бесплатные онлайн-марафоны, 15-минутные созвоны с носителями английского, публичные лекции-презентации Как выучить 5000 английских слов за три дня, разговорный английский по емейл-рассылке и т.д. Думаем, с ними и так все ясно.

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

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

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

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

Чем осознаннее и конкретнее запрос - от хочу поднять мой английский до upper-intermediate до хочу, наконец, разобраться в разнице между present simple и present perfect - тем более планомерным и последовательным будет обучение, а значит, тем ближе к учебнику.

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

Да, хорошие учебники - это дорого. Но ведь и хороший софт - это небесплатно.

Подробнее..

Коммуникация как понимать друг друга даже на удаленке

22.03.2021 22:08:50 | Автор: admin

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

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

Собеседник вас слышит, но понимает немного по-своему. Потому что за каждым словом стоит значение, и оно разное для всех. Например, представьте себе собаку. Представили? Напишите в комментах, как выглядит ваша собака. Я представила какую-то небольшую пятнистую болонку. Скорее всего, вариантов собак будет столько же, сколько и читателей. А теперь ближе к делу. Представьте, что вам нужно, чтобы кто-то внес некие правки. Вы говорите ему:"Внеси нужные правки". Вы понимаете, что нужны правки а и б. А вот ваш собеседник по умолчанию думает, что нужны правки в и г, и их и вносит. Он сделал то, что просили? Да, он же "внес нужные правки". Цель достигнута? Нет, правки же не те!

Почему так происходит? У нас есть фоновые знания, которые мы используем в общении. Это наш опыт, наши смыслы, наша картина мира. Например, я думаю, что во всех документах нужно, например, поменять "-" на "". На фоне у меня лингвистический перфекционизм, Chicago Manual of Style, разговоры с пруфридером, ну, и мое представление об эстетике текста. И вот я говорю об этом нашему локализатору (Женя, привет!). Но когда я с воодушевлением предлагаю такое изменение, реакция не совсем та, которую я ожидаю. Женя против. Как так? Почему? И как нам понять друг друга?

Очень просто. Нужно поделиться фоновыми знаниями. Какие фоновые знания у нашего локализатора? Стоимость. Изменение даже одного знака делает сегмент не полностью распознанным у вендора, и при переводе за каждое такое предложение будет браться плата, и немаленькая. А перевести надо на несколько языков. Получается солидная сумма. И за что? Только за то, чтобы одно тире на другое поменять? Очевидно, что унас разные фоновые знания и ценности. Поэтому мы разговариваем и объясняем друг другу наши аргументы и точки зрения. Так создается общий информационный фон, который помогает нам обоим принять решение в новой, общей системе ценностей. Ура, коммуникация состоялась!

На этом от теории коммуникации переходим к практике.

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

И все-таки сбои в коммуникации бывают. Как их распознать, как угадать, что вот сейчас вас не так поняли? А очень просто - по неожиданной, нелогичной реакции собеседника. Например, он совсем не соглашается, или соглашается слишком быстро. Это серьезный повод задуматься: он точно вас понял? Если, например, до сдачи осталось 2 дня, вы говорите, что нужно еще три недели, а вам говорят: Конечно, не вопрос! Задумайтесь, человек точно вас услышал? Попробуйте создать общий информационный фон, поделитесь своей информацией. Еще раз скажите, медленно и четко, что 3 недели больше 2 дней (surprise-surprise). Есть, конечно, соблазн, всё подписать и убежать, пока все согласны. Но все равно это всплывет, и скорее всего, в самый неподхдящий момент. Я думаю, что не стоит уходить от конфликта, нужно наоборот прояснить его и решить как можно раньше. В примере конфликт сроков явно есть, и, хотя сегодня все соглашаются, в день сдачи будет взрыв.

С другой стороны, иногда кажется, что вас и так понимают, и дополнительно объяснять ничего не надо. Это очень опасная иллюзия. Если вы точно знаете, чего хотите от другого человека, то так и скажите, дайте ему все детали. Плохой пример: Сделай все нужные документы. Хороший пример: Сделай онлайн-справку, пдф на сайте, и справку в продукте. Не поленитесь сразу прояснить все детали, потом будет легче. Лучше перестраховаться. Проясните все критичные детали, а со всем, что некритично для вас, пусть человек разбирается сам.

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

Отдельно стоит написать про удаленку. По зуму или в переписке, конечно, сложнее достичь взаимопонимания.

Прежде всего, выбирайте способ общения в зависимости от того, какая у вас цель:

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

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

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

Подробнее..

Корпоративный английский кто в выигрыше?

10.05.2021 18:20:09 | Автор: admin

Как вы можете учиться на самом деле, а не в фантазиях ваших HR'ов.

Корпоративный английский это практически must have в любой уважающей себя компании. Со своей стороны все уважающие себя языковые школы и фрилансеры обязательно предлагают корпоративный английский.

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

Тему корпоративного английского мы обсуждали с коллегами неоднократно. Потому что нет ни одного из наших коллег ближнего и дальнего круга в возрасте от 25 до 60 лет, кому бы не довелось поработать корпоративным преподавателем английского.

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

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

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

Второй вывод. Основная сложность - в коммуникации с заказчиком на этапе переговоров.

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

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

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

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

В таких обстоятельствах шансы встретиться у сотрудников и тех преподов, которые хотят все сделать правильно и не навредить, невелики.

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

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

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

  1. Нам нужно улучшить английский наших сотрудников

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

  3. Мы хотим дать нашим сотрудникам английский как бонус, плюшка такая

  4. У нас есть 40 человек, и наш босс сказал, что надо учить английский

  5. Нам нужен корпоративный английский, потому что мы хотим понимать, что наши партнеры говорят у нас за спиной

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

  7. Нашей компании нужен носитель английского

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

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

А так выглядят внятные ТЗ:

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

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

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

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

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

Зачем сотрудникам нужен английский?

деньги

время*

результат

мы выбираем

писать деловые письма

не очень дорого

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

простой и осязаемый

читать профессиональную литературу**

бесплатно

все свободное

все вопросы к себе

общаться с коллегами на профессиональные темы

дорого

несколько стандартных курсов

зависит от уровня языка и способности к коммуникации

разговаривать с заказчиками и исполнителями

дорого

несколько стандартных курсов

зависит от уровня языка и способности к коммуникации

уверенно говорить на разговорном уровне

дорого

несколько стандартных курсов

появится на уровне upper-intermediate

выступать на конференциях

дорого

несколько стандартных курсов

появится на уровне upper-intermediate

понять, когда митинг подходит к концу, и вовремя сказать bye

недорого

быстро

доступен на любом уровне

чтобы был, - может, когда пригодится

не платите за это

вечность

не пригодится

чтобы эйчар мог поставить галочку, что в фирме есть корпоративный английский

даром

на заключение договора

галочка

*рассчитывается относительно стандартного курса в 60 ак.часов (15 недель, по 1,5 часа 2 раза в неделю, не включая домашку)

**преподаватель не нужен

Почему сотрудникам нужен английский?

деньги

время

результат

мы выбираем

потому что им обещали повышение зп за английский

дорого (вкл. повышение зп)

зависит от шага повышения зп

часто хороший, но чаще никакой

потому что босс так сказал

фирмы

сотрудников

пусть сам учит свой английский

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

не платите за это

курс закончится не успев начаться

неясный

потому что мы обещали им плюшки

недорого

курс закончится не успев начаться

неясный

потому что недостаточное владение английским существенно ограничивает их доступ к информации

дорого

несколько стандартных курсов

появится на уровне upper-intermediate

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

дорого

несколько стандартных курсов

появится на уровне upper-intermediate

Как часто сотрудники готовы учиться?

деньги

время

результат

мы выбираем

сколько им скажут, столько и будут

сколько выделят

пока все не надоест

плохо прогнозируемый

один раз в неделю по часу

дорого

вечность

неясный

два раза в неделю по полтора часа

дорого

несколько стандартных курсов

простой и осязаемый

15 минут в день

бесплатно

15 минут в день

нулевой

а мы не знаем, как пойдет

смотрите сами

сколько получится

как пойдет

а как часто надо?

по рынку

пару раз в неделю

предсказуемый

Как долго сотрудники готовы учиться?

деньги

время

результат

мы выбираем

нам бы побыстрее

дорого

половина рабочего и все личное

будет, если действительно горит

с нового года до отпуска

дорого

несколько стандартных курсов

предсказуемый

пока есть деньги на это

сколько есть

на сколько хватит денег

на сколько хватит денег и времени

у нас есть полгода

дорого

несколько стандартных курсов

предсказуемый

Как вы хотите учиться?

деньги

время

результат

мы выбираем

только говорить на разговорные темы

не платите за это

вам его не жалко?

нулевой

без скучной грамматики

бесплатно

не тратьте свое и наше

речевое расстройство

без письменной домашки

очень дорого

очень долго

очень нескоро

по учебнику*

по рынку

прописано в программе учебника

предсказуемый, прописан в специальном разделе учебника

чтобы грамматику объясняли на русском

по рынку

такое же, как при объяснении грамматики на английском

на английском

только не по учебнику!*

дороже, чем по учебнику

стандартное

зависит от квалификации препода

без дурацких игр

за ваши деньги не проблема

не сократится

предсказуемый, без дурацких игр

только на английском

по рынку

стандартное

предсказуемый

онлайн без камеры

очень дорого

стандартное

хороший у тех, кто раньше боялся говорить

так, как раньше учили меня, - не очень демократично, но результат был

плётка входит в стоимость

прошедшее

за ним к тому, кто вас раньше учил

только не так, как меня учили раньше

по рынку

настоящее

давайте попробуем

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru