coub.com/view/5lm36
 

Я - верстальщик. Вы - менеджер. Рискну предположить что я - необязательно именно верстальщик, а скажем аутсорс-разработчик вообще.

 

Создавайте определенность

А не просите её.

Сроки

Вы спрашиваете "когда?". Не спрашивайте. Сами скажите когда. Задайте определенность - толи так сказал клиент, то ли вы сами так хотите, то ли это ваш эксперимент, хоть что - мне все равно, главное чтоб ВЫ задали рамки, а не я.

Итак прежде чем спрашивать меня о сроках - выясните сначала для себя а какие вам сроки нужны. И затем предъявив вашу определенность (ваши сроки) - можно спрашивать вписываюсь я в них или нет. Мне останется только принять или отказаться. Или предложить свою определенность (смогу к такому-то). Но не раньше. Сначала - вы.

Приоритеты

Давая задание - сообщайте её приоритет среди других моих задач. У меня задач всегда больше чем свободного времени. Не зная приоритета задачи - нет способа узнать когда она будет сделана. Не согласовав приоритет - не будет гарантии что ваш приоритет будет реализован (другой манагер придет и скажет не, фигня, делай это).

Загрузка

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

Не делайте из меня трекер задач!

Контекст задачи

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

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

Тревожить разработчика можно и нужно. Но делать это нужно определенным образом. Представьте себе такое слоу-мо:

Slow-Mo

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

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

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

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

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

 

Переписка

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

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

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

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

Ещё - знаю что часто изматывающие формы делового общения проистекают именно из страха меня потревожить. Страх потревожить или вежливость или ещё что там - имеет реальные и правильные причины. Но выводы из этих причин как правило неверные. А какие верные? Ну вот про них - эта статья.

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

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

Ваше намерение

К контексту задачи должно присовокупляться (Фрейд) ваше намерение. Контекст без вашего намерения порождает мой вопрос "и что?".

Например.

"Небо синее". И что?
"Клиенту не нравится то-то". И что?
"(тупо копипаста)" (мат)

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

Нужно писать так:

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

Тут уже становится более понятно что от меня требуется.

 

Баги и правки

Нашли баг? Потратьте время на

  1. Скриншот
  2. Сообщение о вашем устройстве - мак, винда, айфон, планшет? Андроид или нет? Какая версия? Я забыл какое у вас устройство и не запомню в этот раз - это всегда нужно писать опять.
  3. обведите то место где нашли баг
  4. Приложите объяснение как должно быть. Потмоу что это может не баг - это может быть специально сделано. Никто не знает и всем трудно искать по документам которых нет и по исходниками в которых жопа - как должно быть. Выясните плиз сами и напишите.
  5. В идеале +100 очков напишите что должно быть сделано чтобы привести то что есть к тому что должно быть. Типа "подними на пару пикселей вверх" или "посветлей сделай". Или "вот картинка, заменить на неё". Вместо - должно быть так, а что надо сделать - таки догадайся сам.

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

Пункты 1-3 это контекст. Пункты 4-5 - это ваше намерение.

 

Посылание в макет == посылание на хуй

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

  1. сделайте скрин
  2. обведите красным места изменения или привлечения внимания
  3. дорисуйте в идеале нужные изменения - типа поднять или опустить. Или ещё что-то
  4. если нужно в качестве образца что-то из макета - приложите скрин
  5. ОБВЕДИТЕ В ОБРАЗЦЕ НУЖНОЕ МЕСТО

joxi.ru - очень удобно одним жестом наметить место. Не заставляйте меня играть в квест "найди 10 отличий".

Если не знаете как должно быть - не волнует, узнайте (но не у меня! Я - тот кто сделал "баг", забыли?). Проверьте сами на что это повлияет, может это уже было, может это не надо, может это глупости. Может как щас - лучше чем как в макете. Не будьте формалистами, не будьте бюрократами. Не перебрасывайтесь тасками и скринами как бумажками в канцелярии - пропускайте таски через себя, фильтруйте, осмысляйте. А затем формулируйте и сообщайте выводы и ваши намерения. В формате контекст + ваше намерение.

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

Не отсылайте в архивы - дайте мне свою выжимку немедленно!

Бюджеты и стоимость

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

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

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

Не бойтесь прогадать или быть обманутым! Вместо этого объективно осознайте что ваши сомнения - от того что вы все ещё не решили для себя сами ваши бюджеты. Решите и все сомнения отпадут. И будет с чем идти к разработчику.

Вежливость

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

 
 

Исключения из правил, обратные ситуации

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

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

Есть обратные ситуации - когда ваше требование перекрасить что-то в зеленый будет тоже воспринято в штыки. Хотя вроде же конкретика.

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

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

 

Каскад разработки (кратко)

Каждый человек в цикле разработке - это такое звено, такой участок из двух корыт и одной черной коробочки:

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

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

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

И если дизайнер не обращает внимания на свой выход - его верстальщику становится трудно. Если верстальщик не обращает внимания на свой выход - кодеру.

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

У вас, менеджеры действительно трудная работа - нужно знать клиента, но нужно знать и разработчика!

Но не волнуйтесь, у разработчиков тоже трудная работа! )))

С новым годом!