2 заметки с тегом

Видение

8 марта 2016, 16:02

Пока, Букмейт

В декабре я устроился работать в Букмейте. Мне было интересно наладить работу в вебе: организовать команду, придумать план и сделать сайт работоспособным. У меня не получилось — в феврале мы решили расстаться.

Почему так

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

  1. Взялся руководить командой, с которой слабо знаком. Из-за этого нам было сложно понять друг друга. Мелкие разногласия мешали работать. За два месяца я так и не нашёл с командой общий язык.
    Надо было заранее со всеми познакомиться и договориться о том, как будем работать. Я уделил этому недостаточно времени и внимания. Думал, по ходу разберёмся. Не разобрались.
  2. Согласился с принципами, которые меня не устраивали. Другие методы работы с программистами, офис, другие инструменты. Попросту непривычно. Это отвлекает от основной задачи — вместо отлаженного процесса пытаешься работать так, как от тебя ждут. В итоге ни то, ни сё.
    Надо было предупредить ожидания и договориться работать так, как удобно. Внедрять изменения потихоньку. Возможно, Букмейт бы это не устроило, но зато мы бы не потеряли два месяца.
  3. Слабо разобрался в продукте перед работой. Сначала казалось, что всё круто, а потом появились разногласия: по эстетике, дизайну и логике. Я думал, что получится привнести изменения через веб — идиотская идея. Во-первых, это затратно. Во-вторых, от меня ждали другого.
    Надо было разобраться перед тем, как начать работать, и не строить ложных ожиданий. Договориться обо всём на берегу. Шанс был.

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

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

Слово Аркадию Чугунову

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

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

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

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

Спасибо за работу.

Спасибы и респект

  • Максу Балабину — за способность по-другому смотреть на вещи
  • Аркадию Чугунову — за умение всё расставить по своим местам
  • Глебу Сологубу — за ненависть к тупняку
  • Кате Ерезе — за критику и помощь с направлением
  • Наде Юриновой — за критику и чёткий подход
  • Кате Ольховой — за желание сделать круто
  • Карине Шегай — за доброту и котиков
  • Александру Персиянцеву — за дружескую подержку

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

Докладываю: это не важно. Все эти скетч или фотошоп, верстать дизайн или рисовать макеты, пилить прототипы или не пилить — это холивары ни о чём. В отрыве от задачи не несут никакой пользы.

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

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

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

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