Это, пожалуй, самый трудоемкий пост на моем канале. Я собирал его несколько недель, опираясь на личный опыт и книги по теме. Материал получился объемным и, возможно, спорным, но это мой взгляд. Вместо критики прошу встать на мое место и подумать: почему я выделил именно эти советы и почему они выглядят именно так
🥇Нацеленность на результат
Успех не меряется усилиями. Он меряется результатом
Я начал свой путь разработчика в МГТУ им. Баумана, где меня окружало множество талантливых ребят, которых без сомнения можно назвать технарями от мозга костей до кончиков пальцев. Во время нашего обучения у нас был предмет под названием "Основы экономики", на который ходило от силы 20% студентов, в числе которых был и я. Главным аргументом тех, кто пропускал пары, было то, что этот предмет нам не пригодится в будущем как специалистам. Я же считал и считаю иначе, потому что большинство из нас работает в коммерческих компаниях, главная задача которых зарабатывать деньги. Любой сотрудник такой компании это часть одного большого механизма. Весь наш труд направлен на то, чтобы компания заработала деньги, из которых нам выплатят зарплату. Из этого плавно вытекает моё первое правило: "Нацеленность на результат"
Давайте разберу ситуацию из собственного опыта
Однажды мы выпустили релиз, в котором перестали работать встроенные покупки. Деньги у игроков списывались, но товары не доставлялись. Активная аудитория — более миллиона человек. Это был настоящий провал!
В 9 вечера мне позвонил менеджер на личный телефон и описал проблему. В тот момент я был на тренировке. Передо мной стоял выбор: бросить всё и срочно спасать ситуацию или ответить, что рабочий день закончился, и заняться этим завтра. Я выбрал первое, потому что руководствуюсь принципом "Нацеленность на результат"
Уже в 9:30 я сидел за компьютером, созвонился с менеджером, и мы провели на связи около восьми часов. К 5 утра мы залили билд с исправлением и попросили быструю модерацию у стора. Позже выяснилось, что проблема была на стороне бэкенда, и технически я не был виноват. Но вместо того чтобы "отмыться", я сделал всё, что мог и мы спасли проект от огромных финансовых потерь, а возможно, и от полной гибели
И это касается не только эпичных ситуаций, но и вполне бытовых
На одном из проектов QA-команда работает посменно 7 дней в неделю, чтобы обеспечивать поддержку клиентов даже в выходные. Иногда мы выкладываем сборку в пятницу, чтобы за выходные провести полное тестирование и в понедельник сделать релиз
Однажды мы поставили сборку в пятницу вечером, и она не собралась. Поскольку сборки занимают несколько часов, результат я увидел только в субботу, в пятницу ночью и весь день в субботу у меня был перелёт с длинной пересадкой. Уже в аэропорту, во время пересадки, я заметил, что сборка упала. Сидя там, я потратил около двух часов на поиск и исправление ошибки, после чего запустил новые сборки и они успешно собрались.
Команда QA провела тестирование в воскресенье, и в понедельник мы выпустили релиз, как и планировали
Поэтому правило: Нацеленность на результат прочно закрепилось в списке моих личных софт-скилов
💬 Говорите просто о сложном
Инженер — это человек, который перед тем как рассказать шутку, проводит 40-минутную лекцию, чтобы собеседник мог её понять
Если бы мне платили доллар каждый раз, когда на синке разработчик говорит: "Да у нас в классе SerializationService сериализация бинарная, а не JSON"... А, стоп, погодите мне же за это и платят. Я же перевожу с технического на менеджерский
Продактам, менеджерам, художникам не важна архитектура проекта, классы или другие технические дебри. Они в этом не разбираются и не обязаны. Поэтому важно уметь говорить о техническом без технического жаргона
Представьте, что продакт однажды скажет:
«У нас есть валидированный юзер-фидбек, метрика drop rate по воронке просела на 12%, а фича уже behind по roadmap».
Вот именно так звучим мы, когда начинаем говорить "по-своему" со всей остальной командой
🤷♀️ Не будьте загадкой для своей команды
Сюрпризы для дней рождения, а не для команды