10+ шрамов дизайнера

Vanilla Thunder
DesignSpot
Published in
20 min readSep 7, 2019

--

Возможно, эта статья будет немного выбиваться из общего потока. Да, она основана на опыте. Возможно даже она будет полезна. Но она точно не будет напоминать пафосные разглагольствования о том, как удачно все вышло, какой хороший прирост конверсии мы получили и как превосходно отлажены наши процессы. Это всё есть, но наши с вами следующие 20 минут будут скорее походить на посиделки двух друзей с крепким алкоголем, где я, изрядно подвыпив, буду красный как бурак рассказывать о ночи с одноклассницей в лагере, наполненной страхом и отвращением к себе. А вы будете кто ржать, а кто восклицать «Ты? Вот так? Фууу!». Не сдерживайтесь, я стерплю.

Теперь немного о формате. Не так давно я прочёл книгу, которая оставила на мне неизгладимое впечатление. Это была «45 татуировок менеджера», где Максим Батырев раскрывал перед читателем принципы своей жизни и работы, густо приправляя их реальными историями. И взглянув на своё испещрённое шрамами опыта тело, я подумал, что мне тоже есть чем поделиться. Этим-то я и спешу заняться.

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

Научись играть по правилам, а потом придумывай свои

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

С тех пор я наблюдал много псевдо профессионалов, которые впрыгивают в проект с криком «Говно! Нужно всё переделать!» абсолютно не задумываются о том, почему какие-то решения уже были сделаны. Потом фантанируют «как нужно», потом нарываются на вилы технических и не очень ограничений и возвращаются к тому, что было в самом начале.

Этот цикл я наблюдал многократно, и пару раз сам скакал с шашкой наголо и стрелял себе в ногу. Но самым ощутимым прозрением стал день, когда я оказался по другую сторону баррикад. Дело касалось нашей внутренней дизайн-системы. Изначально, это было творение всего нескольких людей и уже выстроенная структура атомов, неймингов и элементов были такими родными. Пока не пришли они… новые контрибьюторы. Я прям слышал хруст новых порядков, и мне было обидно и горько. «Да что ж вы делаете, ничего святого в вас нет! Это все уже давно продумано и придумано, зачем ломаете?»

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

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

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

Ещё Эрик Берн в своей «Структуре и динамике социальных групп» описал исследование, где старался определить, что отличает популярных детей от непопулярных. И пришёл к интересному выводу. В детском саду большей популярностью пользовались дети, которые, попадая в группу, не сразу начинали диктовать свои правила игры. Популярнее были те, которые присматривались за тем, как играют другие дети и по каким правилам, а после мягко интегрировались в среду. Причём через какое-то время их предложения встречали явно больший интерес и отклик.

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

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

Мораль: не прыгайте в омут с головой, а лучше изучите обстановку, узнайте как и что работает, а только после действуйте. Не ведитесь на провокации, а если кто-то будет отжимать вас словами «Ты что, не понимаешь, что мы делаем?», то просто ответьте «Я профессионал, потому и задаю так много вопросов, разбираясь в происходящем».

Ошибайся и делай работу над ошибками

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

И раз уж мы затронули тему нашей дизайн-системы, давайте я расскажу, как лихо я обосрался. Для нашей системы мы выбрали Atomic Design подход, где сперва вы определяете атомы, из них строите молекулы, потом организмы, темплейты и страницы.

И как вы можете понять, изменения на атомарном уровне влекут за собой каскад правок во всех остальных компонентах. Потому мы потратили довольно много времени на определение наших базовых сущностей: типографики, сетки, цветовой палитры. Последней мы уделили отдельное внимание: смещение цветового тона к синему при затемнении, уплотнение светлоты для создания равномерного распределения, тесты accessibility… весь фарш короче.

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

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

Мораль: ошибаться — хорошо. Главное это понимать и признавать. Идеально не получиться. Никогда. Смиритесь с этим и делайте все, что можете. Принимайте ошибки, они сделают вас лучше.

Делай одну вещь за раз

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

Я помню, когда я только присоединился к Digital Platform, самой частой фразой, которую я слышал была «Ну там ещё один проектик подкатил. Возьмёшь? Он очень маленький, и там почти ничего не нужно делать… наверное». Порой эта фраза звучала несколько раз в день. Работа же походила на интерстеллар: садишься с утра и в варпе телепортируешься в вечер. Потом, проекты закончились и начались люди. Команда набилась и начались всякого рода дополнительные активности, словно жонглёру закидывали ещё один шарик, заставляя всё быстрее перебирать руками.

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

Если кто-то из вас оказывался перед такой ситуацией один на один, то я готов спорить, что вы могли пытаться перераспределить свою нагрузку. Вот на этом проекте я буду работать на 40%, а вот тут хватит и 20%. И ещё я готов спорить, что вы поняли, что это нифига не работает — это самообман. Даже 1% на любом проекте превращается в 100%, стоит прилететь какой-то «неотложной» задаче, а вы ещё с командой не общались, и воркшоп для менеджеров уже завтра. Всё в огне, всё горит, а вы, как хозяин ада.

Да и ваша авоська порвётся. То есть, если представить все ваши задачи в виде апельсинов, которые вы кладёте в авоську, такую сеточную, как у деда, то попытаясь впихнуть невпихуемое, авоська прорвётся, и оттуда что-то вывалиться. То есть задача просто затеряется, не сделается, а по шапке получите вы.

Выход? Определить приоритет. Заметьте, не приоритизировать все задачи по модели Кано, матрице Эйзенхауэра или ещё как-то.

А определить одно дело, выполнив которое, всё остальное станет проще или вообще не нужно.

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

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

Был у нас на платформе соблазн применить стратегию «Моя хата с краю, ничего не знаю», типа скинуть стейкхолдеров в яму с оружием, и пусть мол разбираются сами, чью задачу делать раньше. Однако такой подход не очень годится: во-первых, вы занижаете свою значимость, как специалистов, а во-вторых, проявляете безответственность.

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

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

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

Мораль: Сосредоточьтесь на чём-то одном, даже если это вызовет хаос в других областях вашей жизни. Не тратьте своё мыслетопливо впустую и учитесь говорить «Нет».

У каждого свой интерес. Научись договариваться

Как говаривала моя учительница по «ОБЖ», свеженький случай. Если вы когда-то вели дела с большими компаниями, то должны знать о том, что там, помимо заказчика наличествует ещё одни ребята, с которыми нужно считаться. Они носят много названий, аки многоликий бог из Игры Престолов: отдел по связям с общественностью, бренд-менеджеры, амбассадоры визуального языка. Мы же свой такой отдел называем нежно и ласково — маркетинг.

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

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

Со встречи я ушел в смешанных чувствах злости и недоумения: как так, мы на этом собаку съели, мы знаем, как лучше, а они так с нами обращаются! Однако по утихнув в сердцах, пришло осознание, что они в какой-то мере правы. Не полностью, конечно, но понять их чувства я мог вполне: мы тут кровью и потом выдавливали из себя палитру, страдали, утверждая её, а тут пришли какие-то чужаки и навязывают свои порядки. Поэтому, интерес из иррационального, превратился во вполне обоснованный — оберегать результат своей работы.

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

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

Мораль: чтобы всё получилось, как вы хотите, вам придётся много с кем договориться. Так что качайте ветку софт скилов. Например, попробуйте себя в сфере обслуживания клиентов.

Лучше проси прощения, чем разрешения

Перефразируя Барри Шварца, я, с вашего позволения, отмечу, что количество менеджеров на проект обратно пропорционально вероятности принятия хоть какого-то решения. А отсутствие хоть какого-нибудь решения максимально негативно сказывается на продуктивности.

Говоря об этом в контексте нашей платформы мне в голову сразу приходит один из сервисов по постановке целей и саморазвитию. Я не берусь судить о ситуации, ибо не знаю интересов всех заинтересованных лиц. Однако с нашей стороны ситуация там была довольно скверная, так как решения по сути не принимались вовсе. Была команда аналитиков и разработчиков, готовая к работе, но распоряжений не поступало и они занимались тем, что «красили траву», помогая на других проектах. Может показаться, что это благодатная почва для всякого рода рефакторинга, тестирования и инноваций. Вот и нам так показалось. Делать же нечего.

Ведомые юношеским максимализмом наша команда закопалась в аналитику и опросы. Данные были неутешительны: bounce rate доходил до 97% спустя всего 3 дня использования, люди считали сервис перегруженным, а основным его конкурентом были стикеры на мониторе (которые работали лучше).

Приняв всё во внимание, мы предложили довольно существенные улучшения портала, включавшего смену фокуса, удаление ненужных функций и упрощение информационной архитектуры. С радостью в голосе мы презентовали свои идеи, но отклика в душе проектного менеджера они не нашли. «У нас есть своя ниша. 4 000 активных пользователей — это же много!» А то, что эта цифра не сдвинулась ни на десяток, хоть компания выросла с 10 000 до 30 000 никого не смущала. Керосина в костёр подлил и деливери менеджер, который прикипел к существующему решению и несмотря на протирающую штаны команду, то и дело ронял «Слишком дорого. Нет Capacity». До сих пор бросает в дрожь, когда слышу эту фразу. Не разрешили.

Но проблема-то осталась не решена. Люди по-прежнему страдали. И мы не оставили нашей идеи, а создали концепт нового портала, который носит кодовое название Level Up.

Построили мы его на слезах реальных пользователей, их болях, взятых из интервью, опросов и часов идеаций и воркшопов. Хоть не обошлось без изменений, зато идея откликнулась другой команде под началом Антона Золотарёва, за что ему большое спасибо. На данный момент ситуация свелась к шаху. Так как у нас есть два конкурирующих сервиса остаться должен только один, и либо первый начнёт переделываться, либо Level возьмёт Up, а старый отстрелят. В любом случае, проблема будет решена. Так или иначе. За что, наверное, я должен попросить прощения.

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

Делай то, что другие делать не хотят, и так, чтобы не было стыдно перед самим собой

Проверить есть-ли такой шрам у вас очень просто. Давайте представим, что проект над которым вы сейчас работаете сегодня должен быть передан другому дизайнеру, а вас отправляют в Куала-Лумпур. Как вы думаете, открывая ваши исходники, с губ дизайнера-последователя сорвётся «Уау! Как круто!» или «Уау! Вот это адище…». Что вы при этом испытаете? Гордость или стыд?

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

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

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

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

Идеи, как вино — дай им настояться

Знаете, я думаю что идеи ничего не стоят, пока не будут реализованы. А это с ними происходит довольно редко: то отфильтруются здравым смыслом, то их зарежет менеджер, то попадут в жернова технических ограничений. И зачастую, когда с нашей идеей случается какая-то беда, мы о ней быстро забываем: нет так нет, с глаз долой из сердца вон. Но что делать, если идея действительно стоящая, а её душат и травят со всех сторон? Ответ я нашёл в магическом числе респауна идеи.

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

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

И хоть нас, такая идея заставляла кусать губы в блаженном благоговении, аккаунт менеджер послал нас… искать бизнес вэлью. Мы его конечно, нашли, но посчитать убедительно не смогли. Посему идею решили пристрелить. Но она была слишком хороша, чтобы умереть. Она поселилась зёрнышком в голове, прям как в фильме «Начало».

А теперь стоит вернуться к волшебной цифре респауна идеи, о которой я говорил выше. В EPAM эта цифра составляет ровно год. Как вы думаете, что происходит за это время? Зёрнышко созревает и дает всходы.

То есть ровно через год, к нам пришёл ровно тот же менеджер и говорит: «Слушайте, а что если нам замутить такой компонент, который бы прорастал во все части нашей платформы и помогал людям…» На что мы ответили: «Отличная идея!» тем паче, что за это время мы успели подумать над бизнес-ценностью и немного метаморфировать идею: теперь там живёт чат-бот, которому пересадили мозг, release notes каждого проекта и запросы в support. В планах интегрировать туториалы для каждого тула.

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

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

Набивай свою коробочку

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

Взяли реальный проект. Один коллега, тот, что говорил, что процесс не нужен, сделал зарисовку на листике, как всё получится в итоге и снабдил рукописными пояснениями, и запечатал в конверт. Второй же прошёлся по полному циклу: анализ конкурентов, интервью с пользователями, построение всякого рода артефактов, прототипирование, тестирование… И в итоге пришёл точно к таким же решениям. Думаете я сейчас скажу, что исследование не нужно и что дизайн-процесс — отстой? Нет.

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

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

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

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

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

Сделать можно всё

В далёкие времена, когда ещё какие-то проекты делались в Photoshop, я стал свидетелем одного интересного случая. На одном из митингов, при обсуждении обсуждении нового концепта, который разработал мой коллега. После окончания презентации, представитель команды разработчиков, без промедления выпалил: «Мы не можем этого сделать. Это невозможно». Задача была не из разряда невозможных, никакого VR или искусственного интеллекта, простой адаптив некоторых компонентов. И я было уже хотел поднять руку, но мой коллега меня опередил. С невозмутимым лицом он ответил: «Как жаль, что я уже слил все слои, и у вас не осталось ничего кроме png и необходимости сделать это».

Нет, я не говорю, что это война — они или мы. Типа даёшь ультиматумы. Нет. Мы все прекрасно понимаем, что порой из-за технических ограничений рациональнее пойти на компромисс, внести незначительные изменения, чтобы упростить жизнь разработчикам, но чтобы пользователь не пострадал. Однако в моменты, когда звучит фраза «Это невозможно», так и подмывает заменить её на «Ты просто не знаешь как». Гайз, камон, мы живём в просто удивительное время, когда слово невозможно вообще должно пропасть из нашего лексикона, за исключением фраз «Когда-то это казалось невозможным».

Моё техническое образование, кроме диплома собирающего пыль, годится ещё на то, что я знаю, что сделать можно всё. И порой даже были случаи, когда я приводил не просто примеры реализации, как реф, а даже выполнял пируэты в codepen, что отрезвляюще действует на команду разработки. И при этом, даже если вы не обладаете техническими знаниями, вот вам простой совет, как отличить плохого разработчика от хорошего: первый говорит «Это не возможно», а хороший говорит «Это сложно».

Отличный разработчик говорит: «Я пока хз, как это сделать, но мы зафигачим!».

Мораль: сделать можно всё. Кто говорит иначе либо недостаточно компетентен, либо пытается вас одурачить.

Начинай, как можно раньше

Вам бабушка не говорила «Сделал дело — гуляй смело»? А вы задумывались, что мы не следуем её мудрости? Вместо этого мы придумали это великолепное слово «прокрастинация» и откладываем свои дела всё дальше и дальше.

Забавный случай. Ещё когда я работал на фрилансе, меня попросили оценить очередной e-commerce проект. У меня уже было достаточно опыта, но не хватало мозгов, чтобы опыт интерпретировать. Приблизительно такой диалог развернулся в моей голове: «Так ну чё тут. Понты. Валим витрину, карточку товаров, корзину. Да тут на две недели работы. Хотя в прошлый раз я тоже сказал две недели, а там нафигачили правок, в итоге затянулось на месяц. Но там заказчик был неадекватный. Но в позапрошлый раз я тоже сказал две недели, а у меня комп полетел, и в итоге всё равно месяц делал. Но комп-то дважды полететь не может. В этот раз всё будет хорошо. Скажу две недели».

Было у вас такое? Бьюсь об заклад, что было. В ловушку излишне позитивного планирования попадают очень много молодых специалистов не сталкивающихся с этими, так называемыми рисками. Само собой, я научился с этими рисками работать… Добавляя 30% к изначальному сроку. Кто-нибудь ещё так делает? Что я один такой позорник?

Ладно, действительно все такие коэффициенты тоже хреново работают из-за так называемого эффекта выпрямления сроков. Давайте я расскажу историю дальше. Когда уже пришёл работать в EPAM на нашу Digital Platform, а как я уже говорил, проектов накидывалось много, и все требовали эти самые эстимации. Добавление коэффициентов вообще не дало какого-то результата и сроки как факапились, так и продолжили факаписться. И если вы тоже наступали на такие грабли и задавались вопросом, почему это происходит, давайте разберёмся.

Допустим, задача занимает у вас три стори-поинта и это ваша эстимация. Добавляя к этому времени 30% получаем 4 стори-поинта и эту эстимацию вы доносите стейкхолдерам. Но что происходит дальше? Я, например, поступал так: «Ну, я же заложил риски, так что можно пока заниматься более важными делами». Если говорить проще, задача занимает всё время, отведённое на её выполнение. То есть добавляя время, мы только растягиваем сопли. Добавляй-не добавляй, всё равно мы начинаем сразу тратить запас времени, отведённого под риски.

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

Мораль: вместо эстимаций и дедлайнов используйте дату старта.

Тебя уволят. Помни об этом.

Меня, может, после этой статьи. Эта мысль отрезвляет. Помни об этом. Хватит уже этой говорильни. Пойдемте работать.

Большое спасибо, что дочитали до конца, мне очень приятно.

Я же в свою очередь, напомню, что у меня есть канальчик в телеге, на котором я делюсь всякими интересностями и своим мнением о них. Только контент, хоть и не регулярный :)

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

--

--

DesignSpot
DesignSpot

Published in DesignSpot

It's community for researchers, interface and experience designers and ones who interested in this theme.

Vanilla Thunder
Vanilla Thunder

Written by Vanilla Thunder

Dmitry Vanitski, Principal UX Designer, Lithuania

Responses (1)