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

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

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

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

Для эффективной коммуникации нужно много навыков, начнем с начала. Для того чтоб в итоге какие-то задачи были выполнены, очевидно, что нам придется эти задачи ставить и поручать людям. И первое, что необходимо для того, чтоб задача была сделана — она должна быть людям хотя бы понятна, и здесь уже есть трудности. Оказывается одни и те же слова люди понимают по разному, в зависимости от контекста, бэкграунда, настроения и черт еще знает чего. Наши слова всегда понятны нам, но остальные могут в них видеть абсолютно другое — причем у неподготовленных людей такое по началу вызывает дикое раздражение, ведь мы то прекрасно понимаем, что имели в виду и понять это по другому мог только дурак, еще и не переспросил же. Однако при этом сами также часто неправильно понимаем других, но в этом случае это конечно же потому, что это они все плохо сформулировали, ага. Посмотрите крутое старое видео https://youtu.be/w7F80U-pPVk?si=34JJCAXw4VgMWz6E отличная демонстрация того, о чем я говорю. Классное упражнение, понаблюдайте за детьми в том числе в сравнении друг с другом. Что можно для начала коротко извлечь отсюда:
1) Точность формулировок и передача полного контекста по задаче сильно улучшает результаты.
2) Нас все равно могут не понять, и в этом нет ничего страшного, нужно контролировать выполнение, и уточнять моменты по опыту. Полезна и аналогичная мысль, что и мы, видимо, настолько же часто неверно понимаем других людей, и постараться уменьшить такие случаи задавая больше вопросов, и озвучивая свое понимание, чтоб нас могли поправить заранее. 
3) Исправления и неудачи это не катастрофа, а эмоции и раздражение наш враг. Уход в раздражение замедляет решение проблем, и ухудшает результаты исправлений сделанных под ним. Учимся стрессоустойчивости и принятию.

Продолжим тему коммуникации. Сегодня о переговорах в случае проблем.

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

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

Исполнителю хочется конечно взять и выдать этот идеальный результат. Но иногда это невозможно. И нужно что-то делать в неидеальной ситуации. Хорошие новости в том, что большинство людей с опытом понимают, что без проблем — не бывает. И то, как вы строите взаимодействие при проблемах даст больше лояльности, ведь проблемы все равно будут, а если человек в них действует прозрачно и понятно, с ним можно работать и дальше. Итак, что же делать
1) Даже если кажется, что уже поздно сообщать о проблемах — это не так. В кейсе выше исполнителю это казалось всю дорогу, и каждый раз он жалел, что не сообщил в прошлый
2) Оправдываться не надо, в конфликте попытка защиты будет его только разжигать, проблемы и проебы надо признать. Признание фактов - гасит раздражение, и клиент быстрее начнет смотреть на ситуацию в практическом ключе. Да и честный рассказ о проблемах добавит клиенту понимания ситуации, а это ставит клиента на нашу сторону, и убирает у него мысли о том, что его злонамеренно опрокидывают.
3) Разбирать прошлое в стиле "а вот если бы" нет смысла, лучше рассмотреть какие варианты есть здесь и сейчас.
4) Не надо кормить надежды об "идеальном" варианте — если не прокатит, даже хороший результат будет казаться проигрышем. Идеального варианта может не быть и важно дать клиенту варианты не желаемые, а те что есть на самом деле.
5) Будет отлично добавить перечисление мер для улучшения ситуации в будущем.

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

Завтра, 18го сентября в 18.00 по мск Павел Ананьин, один из наших тимлидов проводит онлайн митап. Расскажет немного о go, проблемах, что он решает и опыте применения в проекте написанном на другой технологии.
Приходите, обсудим, будет интересно, ссылку скину сюда же

начинаем через пол часа

Комменты к трансляции. Если у вас не коннектит - выключите или наоборот включите vpn

Всем привет

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

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

Началось все кстати неплохо, писал основные функции, изучал новое, основа проекта: трансляции и чатики вокруг них на удивление заработали (уж лет 10+ вроде прошло, а как щас помню впервые настроенное webrtc потоковое вещание на nginx с клиентом в виде swf скрипта). А вот с деталями начались проблемы. Ведь критерий сдачи был не "реализовать трансляцию", а целиком повторить сервис Х в нашем оформлении. А пока я делал самую основу - проект-донор уже успел запилить с десяток новых фич, и видоизменить некоторые старые. Но это было еще полбеды, страшнее было то, что объем нюансов и деталей был сильно больше, чем казалось изначально. Чем подробнее я разбирал задачи - тем больше всплывало что еще нужно реализовать. В итоге, чем больше я делал - тем больше было нужно, работа казалась бесконечной, дизмораль росла.

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

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

Всех с началом очередного рабочего года!

Продолжая традицию из года прошедшего подведу какие-то его итоги

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

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

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

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

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

Ищем проджект менеджера

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

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

Удаленка. Вилка на старт с отсутствием опыта 50-80, при наличии релевантного опыта обсуждаем соответствующие ставки выше, пишите по любым вопросам в личку @navlis23

Буду также благодарен за рекомендацию подходящего кандидата