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

Чётко видно два подхода. Одни говорят – я в самом деле не знаю, как это сделать, и не встречал, как это кто-то делал бы. Но попробую разобраться. И идёт разбираться, кто-то быстрее, кто-то медленнее, но, в конечном итоге, всё сростается и основная здесь проблема – получить новичку время на исследование-обучение + договориться с дизайнером, что и как они будут делать. Вторые дизайнеров за авторитет не почитают ни в каком приближении, и если эти “художники” добавляют ему каких-то проблем, просто отшивают их, мол, нереализуемо. А заказчики – они что, они качество кода оценивать не будут, для них всё качество заключается в работает/не работает, зато на красивые фантики (заставочки, кнопочки, иконочки) покупаются моментально. Если в компании чрезмерно уделяется внимание внешнему виду в ущерб логике и коду – это плохой метод, потому что в конечном итоге бесперспективный. Но если есть здоровое понимание важности грамотного и красивого интерфейса для утверждения (и дальшейшего развития-совершенствования) проекта, а программер в силу недостаточности опыта не догоняет принятую в качестве стандарта модель – начинается конфликт. В самом деле. Дизайнер, вместо того, чтобы продумывать форму и сценарии показа форм, отношения цветов и отрисованные элементы становится дурацкой пешкой, которая бегает между программером и PM, торгуясь – будем мы делать ТАКОЙ интерфейс или нет (потому что именно ЭТОТ программер, в отличие от ПРЕДЫДУЩЕГО, пока не может быстро реализовать задуманное с графикой). Фигня какая-то.

Капризы со сценариями форм вообще удивляют. Ок, хорошо, сделали прогу, есть у неё триальная версия, возможность зарегестрироваться по ключу и возможность купить напрямую. Есть интерфейсная форма в триальной версии, в которой присутствуют кнопки “Buy” и “Register”. При клике на “Register” открывается модальное окно (т.е. поверх предыдущего, и предыдущее недоступно, пока не будет закрыто верхнее), в котором можно ввести ключ и + опять же кнопки – “Buy”, “Try”, “Cancel”, “Register”, и определён сценарий, что можно ввести ключ, нажать “Register” и зарегестрировать прогу. При клике на “Buy”, ясный пень, уйти на оплату. Для двух оставшихся реализовали следующий сценарий: при клике на “Try” предполагается, что юзер передумал вводить ключ, закрывается модальное и становится доступным предыдущее из триальной версии. При клике на “Cancel” – вообще сюрприз, закрывается вся программа! Спрашиваю – с чего вдруг? Где они вообще встречали такой удивительный по юзабельности интерфейс? Пользователь видит полноценное окно поверх основного – с кэпшином, крестиком (на закрытие окна), функциональными элементами и предполагает, что при нажатии на “Cancel” закроет именно это окно, а не все открытые, не всю прогу целиком. Всмысле нормальный пользователь (а ЦА проги – это как раз не гики оторванные, а среднеобученный юзер, который, к тому же, пользует программу с целью РАЗВЛЕЧЕНИЯ). Программер же в ответ начинает спорить, объясняя правильность именно своего сценария тем, что это же МОДАЛЬНОЕ ОКНО! Здрасьти, говорю, а где ты написал юзеру, что это модальное окно и по Cancel`у закроется и оно, и основное? Где ты вообще оставил обычному юзеру мануал по поводу того, что такое модальное окно и особенности управления модальными окнами?

В общем не важно, через PM, ессно, переразобрали сценарий по формам и кнопкам, на вопрос программера “а как я буду делать вот это…” – отправили всё-таки разбираться, сейчас интерфейс (последнюю версию ещё не видела) должен стать более естественным и привычным. А вот проблему поставить на виндовую форму нестандартную кнопочку (набор картинок, имитирующих поведение кнопки – с кликом, с фокусом, с disable и т.д.) – ещё нет, ещё не умеем, опять. Опять. Блин. Уже предчувствую, как будет колбасить нашего заказчика – он до сих пор считает, что знания это что-то вещественное, принадлежащее компании в целом, и если какая-то технология отработана, то при уходе носителя технологии следующий новичёк прям за неделю всё освоит и реализует как и ожидал заказчик. Я даже знаю, чуть ли не дословно, что он скажет.

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

Но к вопросу о характерах спецов и к вопросу о том, кто как подходит для командной работы – трудно работать, когда один из команды авторитарно грузит тем, что “это сделать нельзя или можно, но нерационально сложно”, когда на торговлю и договорённости тратится излишне много времени. С другой стороны практика показывает, что программеры с подобным характером чаще берут на себя ответственность за свой код, проявляют инициативу и продвигают нестандартные решения. Может, и легче работать, когда программер любую поставленную задачу дотошно и смиренно ковыряет (в большинстве подобных случаев – заваливая сроки), пассивно относится к любой постановке задачи, не вникая в суть. Да, ясно, что через время происходит какая-то рокировка в командах, кто-то сползает до кодера простых модулей – с 10 до 19, кого-то ставят ведущим программером или тимлидером, но какое-то время (вот как у нас в посленовогодний движняк в кадрах) работать тяжело, дизайнеры все как-то напряжены, программеры смотрят на них волком и шушукаются (представляю, что они говорят). Верю, что пройдёт время, и можно будет увидеть талантливых программеров (или середнячков на подхвате), но сейчас они все разделяются на (извините, уважаемые) пассивных и занадто резвых. Что лучше – никогда заранее не знаешь, и только спустя год можно увидеть, что же у нас вышло. Вот из вчерашних дискуссий в прошлом посте интересный коммент:

Если спросить любого (почти) работодателя, то для него будет лучше программист, который средненько делает средние задачи, но честно делает их по 8 часов в сутки.А программист, который готов вылизывать код до блеска, и может написать программу, выводящую свой исходник на языке brainfuck — ему не нужен.
У промышленников всегда больше ценились першероны, чем арабские скакуны.

У меня есть в тему совершенно личный пример. Человек, который на одном месте долго сидеть и бездельничать физически не может, работает в конторе (не нашей) сисадмином – большая распределённая сетка, куча сервисов и все дела. Но он выбил себе свободный график – иногда сутками-неделями сидит в офисе, чего-то там сетапает, настраивает, слушать невозможно про все его офисные приключения. Потом, настроив всё и всем, может неделю не показываться и дальше – периодически на несколько часов заезжать, юзерские проблемы помогать решать. Объясняет это так: а зачем мне здесь сидеть – всё работает! И удержать невозможно было. Так же, как и заставить уйти в шесть вечера из офиса (ага, счас, это вы клиентам объясните, что у меня с 9 до 12 плановая профилактика!). Получается, что этот (и в самом деле талантливый, решающий все проблемы, не имеющий нерешаемых проблем) сисадмин – типичный арабский скакун – штучка дорогая, но малоуправляемая. Крайности, конечно, в жизни всё с менее чёткими границами, и не всегда с первого взгляда-первого рабочего дня получается узнать про новичка и предсказать его будущее. Да и у нас, конечно, всё настроется, не первый раз (увы), просто нужно переждать очередной ледниковый переходной период.

Единственная больная тема – это обучение (дотягивание до уровня) новичков тимлидерами это факт, это расстраивает. Рассказываешь, делишься, тратишь время и не знаешь – через три месяца с полученными знаниями потеряешь специалиста, через пол года, через год? И тема эта актуальна и для дизайнеров, и для программеров. Смотрю, что и в программерской среде у тех наших, что с таким энтузиазмом помогали новичкам ещё год назад, и даже мастерклассы какие-то устраивали – как будто руки опустились. Задатков учительских нет, повторять одно и то же долбоочередным новичкам надоело, до специально назначенных на проведение спецкурсов сотрудников наша компания пока не доросла, да и размеры компании стали заметно больше (новички, может, и подходили бы к старожилам с вопросами почаще, но те рычат, ибо если отвечать всем на все вопросы – они не смогут работать а кто, если не они? На их профессионализме пока всё и держится…). Так что новый год, похоже, принёс новые заботы – что делать с этими цыплятами и как перейти (помягче бы) на более… быстрое обучение сотрудников? Ну и как учить их работать в команде, нормально договариваться между собой, общаться? А то мне это третье за последнее время сообщение “я с этим работать не хочу, я лучше с этим…” мягко говоря, травмирует.