Блог Сергея Копылова

Секрет работы в маленьких группах

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

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

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

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

  • Опросить мнение у всех участников
  • Придумать лучшее решение, учитывающее это мнение
  • Рассказать о нём, услышать возражения, но только один раз
  • Претворить решение в жизнь
  • Нести ответсвенность за последствия решения и менять его при необходимости

Здесь не нужна какая-то формальность в пунктах и последовательности, нужно просто примерно понимать процесс.

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

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

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

P.S. На всякий случай отмечу, что я много раз был как и тем, кто принимает решения, так и тем, к мнению которого просто прислушиваются.

Хорошо поставленная задача

Разберём случай, когда до дизайнера или разработчика доходит какая-то задача, сформированная цепочкой менеджеров и аналитиков по чаяниям заказчика на конкретном примере.

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

Обычно до разработчика доходит какая-то такая задача:

«Необходимо создать страницу с отображением всего списка свидетельств, с возможностью изменения набора столбцов и фильтров. Изначальные наборы столбцов такие-то, наборы фильтров такие-то. Обеспечить разный уровень доступа для разных пользователей, возможность создания и подписания новых документов, выгрузки в EXCEL, XML, CSV, PDF, Word сохранения истории изменений. Ктопку такую-то разместить здесь, такую-то здесь, вот эту сделать зелёной. Набор полей документа формируется с учётом ФЗ № такой-то такой-то, ...»

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

Разработчику говорят, что делать, но не говорят, почему. Нет ответов на следующие вопросы:

  • Почему мы вообще это делаем? Какую проблему заказчика мы решаем?
  • Зачем нужна возможность изменения набора столбцов и фильтров?
  • Что значит разный уровень доступа? Кто вообще будет этим пользоваться и в каком случае?
  • Каким образом должна быть реализована подпись? Физическим ключом в USB? Паролем? Электронной подписью?
  • Что значит «отображение всего списка свидетельств»? Сколько их всего? А если несколько миллионов? Вы уверены, что кому-то нужно сразу видеть миллион свидетельств за несколько лет?
  • Выгрузка миллионов записей из БД с внешними ключами и данными из других таблиц и форматированием в каком-то формате займёт очень много времени и сильно нагрузит базу? Существует ли реальный сценарий использования этой функции?

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

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

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

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

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

Турник и площадка во дворе

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

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

Короче, вот такая штука, как у Лебедева, только с одним турником.

А ещё в подъезде нужно между 4 и 5 этажом турник на стене повесить на зимнее время.

P.S. За картинку спасибо Рите.

Если задумываться — не получится

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

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

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

Вероятно, подобные вещи можно уловить и в отношениях — пока ты переживаешь о каждом неправильном слове, отношения целиком строятся очень медленно.

Но есть и следующий этап.

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

Поэтому задумываться, конечно, очень важно, но важнее — делать, и начинать раньше, чем ты со всем разобрался (потому, что невозможно со всем разобраться).

Хорошо, когда работа идёт без тебя, часть 2

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

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

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

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

Хорошо, когда работа идёт без тебя, часть 1

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

Я задумался. К тому времени у нас была очень простая система прав. У нас было что-то вроде 7 разделов и если кто-то имел доступ к разделу, то мог делать в нём всё. Теперь требовалось сделать так, чтобы для разных пользователей были доступны или нет конкретные действия и кнопки: просмотра, редактирования, удаления.

Но были и плюсы:

  • мы уже обсуждали будущую необходимость появления системы прав с бекэндером и он знал, как это можно сделать;
  • мы никогда не опирались на то, что фронтенд сам что-то контролирует, поэтому запрет редактирования заключался не в скрытии кнопочки, а в том, что и по API редактирование не будет доступно;
  • у нас были конфигурации каждой страницы. Страницы были описаниями какие данные где взять и как их отобразить, а не вёрсткой каждой страницы отдельно;
  • в начале проекта я настоял на том, чтобы каждая страница отображала одну сущность, или один набор сущностей. К примеру, кнопка удаления была только на странице редактирования документа, а не где-то ещё. Запретив переход на эту страницу мы автоматически запрещали и редактирование, и удаление. Сделал я это исходя из удобства пользователю, но оказалось, что это удобно и нам.

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

И пошёл в отпуск.

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

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

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

Про профессиональный рост

Меня часто спрашивали что-то такое: «А не боишься ли ты, что если автоматизируешь свою сегодняшнюю работу, то тебя просто уволят за ненадобностью?» И я видел, как много людей топчатся на месте, лишь бы этого не случилось.

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

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

Про то, как я ответил на вопрос, на который не знал ответа

Сделали мы новый проект и пришло время его тестовой эксплуатации.

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

Представитель заказчика задал какие-то вопросы, о которых мы подумали и на которые я знал ответ и вот прихоло время следующего вопроса. Он говорит:

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

В моей голове завертелось следующее:

  • проблема есть;
  • выносить в отдельную базу, значит, потерять внешние ключи, это значит, что мы не сможем контролировать целостность, и, наверно, появятся ещё какие-то проблемы;
  • программировать что-то для частного случая не хочется, так мы можем придти к 15 БД;
  • любое программирование — это деньги компании и мне придётся объяснить, почему мы это делаем;
  • эта проблема точно возникала не только у нас, множество продуктов хранят историю и вообще очень много данных;
  • мы используем PostgreSQL, это наиболее развитая свободная СУБД и там точно есть решения для этих проблем, когда данные не помещаются на один жёсткий диск.

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

Представитель удивился, сказал, что хорошо, если так и я пошёл на рабочее место. Там я спросил у бекэндера, был ли я прав. Он ответил, что да, и что это называется «внешние таблицы».

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

Поэтому я и трачу существенную часть рабочего времени на то, чтобы этот кругозор нарасти и не потерять.

Про уверенность

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

К тому времени текущие продукты были сделаны на смеси Java + Spring + Angular 1 + JQuery. То есть на сервере хранились .jsp-странички к которым были подключены JS-библиотеки, лежажие прямо здесь, устаревших версий, в которых предыдущие программисты ещё что-то меняли руками, поэтому обновлять их не было никакой возможности.

К тому времени я начитался в интернете о том, что существует какой-то npm-репозиторий с библиотеками, что есть React.js и какие-то другие фреймворки, что есть какой-то компонентный подход, который используется в новом Angular 1.5 в том числе. Ещё мне откровенно не нравилась Java на бекэнде. Мне представлялось, что у нас вырос какой-то невероятный энтерпрайз-монстр, который в первую очередь обслуживал сам себя, а не мифическую высокую нагрузку.

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

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

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

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

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

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

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

Можно делать меньше

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

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

Притом так даже лучше, чем когда ровненько: ты сходу понимаешь, что выделение — часть скриншота, а не самого интерфейса.

Или, например, при работе над дизайн-проектом можно сначала сделать коллаж из мебели, а не 3D-визуализацию. Прикинуть, как будут сочетаться цвета и мебель по нему можно, исправить будет легко, а силы на визуализацию не будут потрачены.

Так что не только можно, а нужно делать меньше.

Ранее Ctrl + ↓