Мы обсуждаем дизайн или реализацию?
Бывает ситуации, когда встречи о дизайне с программистами идут туго. Программисты накидывают непонятные претензии к дизайну:
— Зачем нужна штука X? А почему бы не сделать вместо неё штуку Y.
В ходе обсуждения преимуществ того или друго дизайна становится ясно, что у программистов на самом деле нет доводов сверх «а почему бы», и они вымучивают какие-то соображения со словами «юзабилити», просто чтобы не говорить, что им проще сделать штуку Y вместо штуки X. Кажется, программисты боятся сказать, что что-то сложно, и им хочется как-нибудь поменять дизайн, чтобы получилось, что они молодцы и делают всё, как задумано.
Если вы чувствуете, что такое происходит, стоит задать прямой вопрос:
— Что мы сейчас обсуждаем, дизайн или реализацию? Если вам кажется, что в дизайне проблема, давайте вы её явно назовёте, и тогда мы в команде дизайна подумаем над решением. А если ваш вариант проще в реализации, это тоже можно обсудить, но давайте тогда и обсуждать это, а не «юзабилити».
Потому что если явной проблемы нет, то это просто обмен мнениями с непонятной перспективой. Да, любой дизайн можно сделать ещё и по-другому, и третьим способом тоже. Кто будет принимать решение о дизайне, программисты?
Если же проблема в сложности реализации, то тут нужно не между вариантами X и Y выбирать, а разобраться, в чём сложность. Возможно, дизайнеры предложат вообще вариант Z с учётом технических ограничений.
Дорогие программисты! Не бойтесь говорить сразу о технических ограничениях, не пытаясь замаскировать их под разговоры о дизайне. Чем смелее вы будете в этом, тем быстрее дизайнеры начнут разбираться в том, что у вас там происходит, и тем проще вам в будущем будет находить общий язык. Возможно, дизайнеры сразу начнут приносить удобный для реализации дизайн. А с другой стороны, принося неудобный, они будут вынуждены убедительнее защищать его и обосновывать необходимость приложения особых усилий. Тогда и вы лучше начнёте лучше разбираться в том, что у нас тут происходит.
Это очень странный способ бессмысленного убийства времени. Такие встречи просто не нужны.
Когда мне, как программисту, дизайнер приносит дизайн, я говорю: «Спасибо!» — и приступаю к реализации. Если в дороге выясняется, что в силу исторических вакханалий показать какой-нибудь список, или просто аккумулированное значение, или еще что заковыристое — долго или сложно — я иду к дизайнеру и говорю: «Слушай, мне придется специально потратить неделю, чтобы вот это не тормозило, оно нам действительно надо?» — И если ответ «да» — я иду и делаю. А если «да не особо» — то мы вместе придумываем, как извернуться без добычи медленных данных.
Не существует «сложности реализации» в вакууме. Существуют: «текущая архитектура не позволит этому работать с приемлемой скоростью», «чтобы вытащить эти данные, придется переписать половину бэка», и «я хрен знает как это сделать, а думать мне лень».
Встречи о дизайне с программистами нужны, чтобы объяснить программистам, как что устроено и почему.
Если не проводить таких встреч, надеясь, что программисты сами все поймут, то придется в описании дизайна писать не просто, что должны быть поклеены обои, но еще и уточнять, что на стены.