Учебник для менеджеров в Digital.

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

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

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

pm.chulakov.ru/

Про письма.

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

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

И ещё.

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

Мир вам.

Про обратную связь.

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

Конечно, кто-то может сказать, что объяснять, почему тот или иной человек не подошёл на должность, никто никому не должен и не обязан.

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

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

Я считаю, что обратная связь — элементарная вежливости. А если нет времени на вежливость, то это как-то совсем грустно.

Про страх.

Навеяно постом Саши Першина — https://www.facebook.com/sasha.pershin/posts/1151429824992441.

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

Это не моя фраза, а цитата из фильма «После нашей эры».

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

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

И всё потому, что мы попробовали прыгнуть и перепрыгнули. А кто не пробует, никогда не перепрыгнет.

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

Про алкоголь.

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

Про количество чатов в Telegram.

Я не могу найти свой канал 🙁.

Про иерархию сотрудников.

Ключевой момент в партнёрстве, нахождение точек соприкосновения, когда ваше предложение совпадает со спросом конкретного заказчика.

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

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

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

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

Про делегирование.

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

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

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

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

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

Про темы выступлений.

Для меня всегда доклады делились на три категории.

Доклады с хорошим названием и тезисами, хорошим содержанием и подачей.

Доклады с хорошим названием и тезисами, плохим содержанием и подачей.

Доклады с плохой темой и тезисами, но крутым содержанием и подачей.

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

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

Про нативный CSS.

Через три месяца я буду выступать с докладом на конференции KharkivCSS с докладом про возможность (или невозможность) замены препроцессоров возможностями нативного CSS. Учитывая мою текущую основную деятельность, нельзя терять мостик между менеджментом и технологиями.

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

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

О вдохновении.

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

О сообществах.

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

Про разработчиков.

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

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

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

Вывод дня.

Две головы лучше чем одна. Четыре руки лучше чем две.

Подготовка выступления.

Я научился готовить выступления двумя способами.

Первый — сначала текст, потом презентация.

Второй — сначала презентация, потом текст.

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

Во втором варианте, я собирал презентацию по мыслям в голове. А потом по ней писал опорный текст и потом импровизировал во время выступления.

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

Про трансформацию специализации.

Жизнь сложная штука. Это я понял давно.

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

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

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

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

Илон Маск и сотрудники Space X вчера запустили к Марсу первую ракету.

А в Ракете мы сегодня запустили пятидесятый проект в работу.

Работаем дальше.

Про доверие.

Я изначально планировал сегодня написать про доверие. Про доверие к начинающим специалистам.

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

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

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

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

Про тестирование.

Меня расстраивает тестирование. Меня расстраивает тот факт, что ребята тестируют не то, что нужно действительно тестировать.

Сравним условно два типа тестирования. Первый — соответствие макету точка в точку, второй тестирование доступности.

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

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

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