Здесь не нужна какая-то формальность в пунктах и последовательности, нужно просто примерно понимать процесс.<\/p>\n
А у всех других ребят остаётся право сменить этого человека на другого, если что-то раз за разом не нравится.<\/p>\n
Ещё очень круто, если такими лидерами становятся все в группе, но только в своей сфере: кто-то отвечает за одно, а кто-то за другое. Особенно это круто тогда, когда нужно принимать много решений, а ещё хорошо потому, что каждый чувствует и личную ответственность тоже.<\/p>\n
Короче, никакой прямой демократии, только представительная. Думаю, что и в больших группах всё так же.<\/p>\n
P.S. На всякий случай отмечу, что я много раз был как и тем, кто принимает решения, так и тем, к мнению которого просто прислушиваются.<\/p>\n", "date_published": "2020-03-24T09:49:54+03:00", "date_modified": "2020-03-24T09:39:02+03:00", "_date_published_rfc2822": "Tue, 24 Mar 2020 09:49:54 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "82", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "81", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/horosho-postavlennaya-zadacha\/", "title": "Хорошо поставленная задача", "content_html": "
Разберём случай, когда до дизайнера или разработчика доходит какая-то задача, сформированная цепочкой менеджеров и аналитиков по чаяниям заказчика на конкретном примере.<\/p>\n
Возьму пример из области медицины, в которой проработал несколько лет. В общем смысле задача обычно звучит как-то так: «Отобразить список свидетельств о рождении, которые регулярно приходят из медицинских организаций.»<\/p>\n
Обычно до разработчика доходит какая-то такая задача:<\/p>\n
«Необходимо создать страницу с отображением всего списка свидетельств, с возможностью изменения набора столбцов и фильтров. Изначальные наборы столбцов такие-то, наборы фильтров такие-то. Обеспечить разный уровень доступа для разных пользователей, возможность создания и подписания новых документов, выгрузки в EXCEL, XML, CSV, PDF, Word сохранения истории изменений. Ктопку такую-то разместить здесь, такую-то здесь, вот эту сделать зелёной. Набор полей документа формируется с учётом ФЗ № такой-то такой-то, ...»<\/p>\n
И так ещё 10 страниц. Это совершенно ужасная постановка задачи, которая одновременно подразумевает, что дизайнер или разработчик тупой, как дрова, и может действовать только по алгоритму. И с другой стороны, она перекладывает на разработчика самые ресурорсоёмкие операции, как, например, поиск набора полей в каком-нибудь приложении к федеральному закону.<\/p>\n
Разработчику говорят, что делать, но не говорят, почему. Нет ответов на следующие вопросы:<\/p>\n
- \n
- Почему мы вообще это делаем? Какую проблему заказчика мы решаем?<\/li>\n
- Зачем нужна возможность изменения набора столбцов и фильтров?<\/li>\n
- Что значит разный уровень доступа? Кто вообще будет этим пользоваться и в каком случае?<\/li>\n
- Каким образом должна быть реализована подпись? Физическим ключом в USB? Паролем? Электронной подписью?<\/li>\n
- Что значит «отображение всего списка свидетельств»? Сколько их всего? А если несколько миллионов? Вы уверены, что кому-то нужно сразу видеть миллион свидетельств за несколько лет?<\/li>\n
- Выгрузка миллионов записей из БД с внешними ключами и данными из других таблиц и форматированием в каком-то формате займёт очень много времени и сильно нагрузит базу. Существует ли реальный сценарий использования этой функции?<\/li>\n<\/ul>\n
Ну и так далее. Зато есть ненужные подробности о расположении кнопок и перечисления «как бы» форматов файлов выгрузки. Конечно, здесь очевидно, что менеджеры не смогли узнать реальную проблему заказчика и как решить именно её имеющимися средствами.<\/p>\n
Неопытный разрабочик просто возьмёт это в реализацию не думая и начнёт программировать шаг за шагом. Задача окажется трудновыполнимой даже за несколько месяцев (что его тоже не побеспокоит), всё будет тормозить потому, что для такого общего решения недостаточно просто добавить индексы в БД, чтобы всё работало быстро, и в конце концов, когда задачу покажут заказчику, у него полезут глаза на лоб и он удивится, как такую неповоротливую махину можно было делать несколько месяцев, когда она всё равно не работает, потому, что оттестировать все варианты поведения и отображения такой махины невозможно.<\/p>\n
Если же пообщаться с заказчиком, слушая не только предложенное решение, а ещё его проблемы, то всё станет на свои места. Окажется, что с этим списком должны работать такие-то врачи и работники загса. Что права на изменение и добавление такие-то. Что любые поля нужно отображать, чтобы было видно, отфильтровалось или нет (конечно, здесь нужно придумать другое решение), что вывод всех документов сразу не нужен, а нужен в разрезе по медицинской организации.<\/p>\n
Такую задачу уже можно сделать за неделю, и, даже если какие-то из требований были описаны неверно, у нас есть ещё много времени, чтобы это исправить.<\/p>\n
А может оказаться, что сегодняшнего списка документов любых типов с фильтрацией по типу уже достаточно для решения этой задачи и нам не нужно делать ничего, кроме настройки шлюза для получения этих документов от медицинских организаций. Вот и экономия месяцев труда команды на пустом месте.<\/p>\n", "date_published": "2020-03-24T09:37:32+03:00", "date_modified": "2020-06-09T15:23:09+03:00", "_date_published_rfc2822": "Tue, 24 Mar 2020 09:37:32 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "81", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "77", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/horosho-kogda-rabota-idyot-bez-tebya-chast-2\/", "title": "Хорошо, когда работа идёт без тебя, часть 2", "content_html": "
Когда я собрался увольняться из компании, в которой вёл большой проект со стороны интерфейса, к нам пришёл молодой разработчик сразу после университета. Он не знал конкретных библиотек, которые мы использовали.<\/p>\n
За этот месяц я рассказал ему, что необходимо, и он довольно быстро включился в процесс. По прошествии нескольких месяцев, бывшие коллеги рассказали мне, что так получилось, что сейчас он единственный поддерживает разработку интерфейса этого большого проекта. И что разработка идёт вполне себе устраивающими темпами.<\/p>\n
У него есть мои контакты, но он ни разу мне не писал. Конечно, он может спросить что-то у коллег, но и они говорят, что он не так часто это делает.<\/p>\n
И это комплимент для меня. Если большую систему с сотнями представлений и страниц можно успешно поддерживать не имея большого опыта, то это значит, что та архитектура, те принципы, которые были использованы были правильными.<\/p>\n", "date_published": "2020-03-22T12:38:37+03:00", "date_modified": "2020-03-22T12:38:34+03:00", "_date_published_rfc2822": "Sun, 22 Mar 2020 12:38:37 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "77", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "72", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/rabota-bez-tebya-1\/", "title": "Хорошо, когда работа идёт без тебя, часть 1", "content_html": "
Однажды ко мне пришёл менеджер и сказал, что нужно сделать развёрнутую систему прав. Я был ведущим разработчиком на проекте, у меня оставалось два дня до отпуска, а систему прав нужно было выпускать через 2 недели, когда я ещё буду в отпуске.<\/p>\n
Я задумался. К тому времени у нас была очень простая система прав. У нас было что-то вроде 7 разделов и если кто-то имел доступ к разделу, то мог делать в нём всё. Теперь требовалось сделать так, чтобы для разных пользователей были доступны или нет конкретные действия и кнопки: просмотра, редактирования, удаления.<\/p>\n
Но были и плюсы:<\/p>\n
- \n
- мы уже обсуждали будущую необходимость появления системы прав с бекэндером и он знал, как это можно сделать;<\/li>\n
- мы никогда не опирались на то, что фронтенд сам что-то контролирует, поэтому запрет редактирования заключался не в скрытии кнопочки, а в том, что и по API редактирование не будет доступно;<\/li>\n
- у нас были конфигурации каждой страницы. Страницы были описаниями какие данные где взять и как их отобразить, а не вёрсткой каждой страницы отдельно;<\/li>\n
- в начале проекта я настоял на том, чтобы каждая страница отображала одну сущность, или один набор сущностей. К примеру, кнопка удаления была только на странице редактирования документа, а не где-то ещё. Запретив переход на эту страницу мы автоматически запрещали и редактирование, и удаление. Сделал я это исходя из удобства пользователю, но оказалось, что это удобно и нам.<\/li>\n<\/ul>\n
Я написал за несколько часов заглушку бибилиотеки, проверяющей права. Договорился с бекэндером о том, в каком формате он будет присылать список прав для каждого пользователя. И рассказал своей команде, что именно нужно делать для того, чтобы всё заработало.<\/p>\n
И пошёл в отпуск.<\/p>\n
Когда я вернулся, система была готова и выпущена, в отпуске меня никто не тревожил, а ребята смогли придумать пару вещей, о которых я не успел подумать до отпуска, но которые несколько улучшили систему.<\/p>\n
Я обрадовался. Если ребята могут это сделать без меня, то значит, что код, который я написал понятен, подход, который я предложил тоже, подготовка ребят достаточная, а я могу не тратить время на такие задачи и переходить на ещё более сложные.<\/p>\n
А вот если бы мне каждый день звонили в отпуске, то это бы значило не то, что ребята не знают границ, а то, что я недостаточно хорошо объяснил и подготовил работу.<\/p>\n", "date_published": "2020-03-22T12:25:05+03:00", "date_modified": "2020-03-22T12:27:19+03:00", "_date_published_rfc2822": "Sun, 22 Mar 2020 12:25:05 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "72", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "75", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/pro-to-kak-ya-otvetil-na-vopros-na-kotory-ne-znal-otveta\/", "title": "Про то, как я ответил на вопрос, на который не знал ответа", "content_html": "
Сделали мы новый проект и пришло время его тестовой эксплуатации.<\/p>\n
В компанию приехал технический пециалист заказчика и стал задавать всякие каверзные вопросы. Сначала с ними справлялся менеджер, но в какой-то момент перестал и в кабинет позвали меня, как ведущего разработчика проекта.<\/p>\n
Представитель заказчика задал какие-то вопросы, о которых мы подумали и на которые я знал ответ и вот прихоло время следующего вопроса. Он говорит:<\/p>\n
- \n
- Вы сделали прекрасную историю изменений, которой нет у конкуретнов. Теперь в истории хранится не только время и автор изменения, но и весь слепок версии на то время. Однако, мы боимся, что документы будут меняться часто и история начнёт занимать слишком много места за года использования. На основном сервере мы не можем обеспечить столько места на жёстких дисках, и хотели бы вынести историю в отдельную базу на другом сервере. Можно ли так сделать? Сможете ли вы это запрограммировать?<\/li>\n<\/ul>\n
В моей голове завертелось следующее:<\/p>\n
- \n
- проблема есть;<\/li>\n
- выносить в отдельную базу, значит, потерять внешние ключи, это значит, что мы не сможем контролировать целостность, и, наверно, появятся ещё какие-то проблемы;<\/li>\n
- программировать что-то для частного случая не хочется, так мы можем придти к 15 БД;<\/li>\n
- любое программирование — это деньги компании и мне придётся объяснить, почему мы это делаем;<\/li>\n
- эта проблема точно возникала не только у нас, множество продуктов хранят историю и вообще очень много данных;<\/li>\n
- мы используем PostgreSQL, это наиболее развитая свободная СУБД и там точно есть решения для этих проблем, когда данные не помещаются на один жёсткий диск.<\/li>\n<\/ul>\n
И я сказал: я думаю, что нам не нужно будет ничего программировать. Мы сможем вынести таблицу с историей на другой сервер посредством возможностей СУБД.<\/p>\n
Представитель удивился, сказал, что хорошо, если так и я пошёл на рабочее место. Там я спросил у бекэндера, был ли я прав. Он ответил, что да, и что это называется «внешние таблицы».<\/p>\n
Мораль в том, что проспо подумав и прикинув вероятность того, что что-то работает так, как тебе нужно, ты можешь придумать решение для разных ситуаций. Правда для этого нужен какой-никакой кругозор.<\/p>\n
Поэтому я и трачу существенную часть рабочего времени на то, чтобы этот кругозор нарасти и не потерять.<\/p>\n", "date_published": "2020-03-22T11:56:27+03:00", "date_modified": "2020-03-22T11:57:27+03:00", "_date_published_rfc2822": "Sun, 22 Mar 2020 11:56:27 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "75", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "74", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/pro-uverennost\/", "title": "Про уверенность", "content_html": "
Однажды на работе мне дали задачу сделать новый продукт вдвоём с бекэндером — он делает всё, что на сервере, я всё, что в браузере. И этот продукт должен стать платформой для других новых продуктов. Впрочем, я и сам подводил к тому, чтобы эта задача досталась мне.<\/p>\n
К тому времени текущие продукты были сделаны на смеси Java + Spring + Angular 1 + JQuery. То есть на сервере хранились .jsp-странички к которым были подключены JS-библиотеки, лежажие прямо здесь, устаревших версий, в которых предыдущие программисты ещё что-то меняли руками, поэтому обновлять их не было никакой возможности.<\/p>\n
К тому времени я начитался в интернете о том, что существует какой-то npm-репозиторий с библиотеками, что есть React.js и какие-то другие фреймворки, что есть какой-то компонентный подход, который используется в новом Angular 1.5 в том числе. Ещё мне откровенно не нравилась Java на бекэнде. Мне представлялось, что у нас вырос какой-то невероятный энтерпрайз-монстр, который в первую очередь обслуживал сам себя, а не мифическую высокую нагрузку.<\/p>\n
Если вы не фронтенд-разработчик и не поняли, что написано выше — неважно. Важно то, что я понимал, что сегодняшняя архитектура неимоверно сложна, что есть пути проще и популярнее, и что я совершенно не знал, работают ли они.<\/p>\n
И с этим всем я пошёл на совещание с директорами, для того, чтобы мы с бекэндером представили новый подход к технической платформе. Там мы рассказали об этих новых способах, получили согласие и разошлись работать. На совещании с нами сидел опытный фронтендер, который не занимался этим проектом, но мог что-то прокомментировать. Он сказал мне несколько слов уже после совещания. Они были такими: «У тебя не получится так сделать».<\/p>\n
И вправду, я и сам был не уверен в том, что у меня получится, я же не делал такого никогда. Я был уверен только в том, что другие так делают и у них получается и в том, что не боги горшки обжигают.<\/p>\n
Всё закончилось хорошо. Продукт мы разработали в срок, на его основе выросли огромные проекты.<\/p>\n
Подобные вещи случались многократно, каждую неделю мне нужно было делать что-то такое, что ни я, ни кто-то другой в компании не делал.<\/p>\n
И в этом и суть. Ты растёшь сам и помогаешь расти компании только когда берёшься делать то, в чём совсем не уверен, что справишься.<\/p>\n
Если ты делаешь многократно что-то, в чём уверен, то нужно либо передать эту работу молодому коллеге, или автоматизировать, чтобы не топтаться на одном месте.<\/p>\n", "date_published": "2020-03-22T11:42:47+03:00", "date_modified": "2020-03-22T11:35:13+03:00", "_date_published_rfc2822": "Sun, 22 Mar 2020 11:42:47 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "74", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "68", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/mozhno-delat-menshe\/", "title": "Можно делать меньше", "content_html": "
Часто люди пытаются сделать даже промежуточные работы и отчётами идеальными. Прорисовывают каждую деталь, делают аккуратно, запариваются о пикселях и так далее. Так не надо. А надо так, чтобы решало задачу.<\/p>\n
На работе мы часто обмениваемся скриншотами, на которых помечено куда смотреть. Часто люди ставят специальные программы и следят за тем, чтобы их подчёркивание или выделение были ровненькими. А нужно так:<\/p>\n
\n![\"\"](\"https:\/\/www.blog.sergeykopylov.ru\/pictures\/Screenshot-2020-03-19-at-18.06.46.png\")
\n<\/div>\nПритом так даже лучше, чем когда ровненько: ты сходу понимаешь, что выделение — часть скриншота, а не самого интерфейса.<\/p>\n
Или, например, при работе над дизайн-проектом можно сначала сделать коллаж из мебели, а не 3D-визуализацию. Прикинуть, как будут сочетаться цвета и мебель по нему можно, исправить будет легко, а силы на визуализацию не будут потрачены.<\/p>\n
\n![\"\"](\"https:\/\/www.blog.sergeykopylov.ru\/pictures\/Screenshot-2020-03-19-at-18.06.00.png\")
\n<\/div>\nТак что не только можно, а нужно делать меньше.<\/p>\n", "date_published": "2020-03-19T18:15:33+03:00", "date_modified": "2020-03-19T18:15:20+03:00", "image": "https:\/\/www.blog.sergeykopylov.ru\/pictures\/Screenshot-2020-03-19-at-18.06.46.png", "_date_published_rfc2822": "Thu, 19 Mar 2020 18:15:33 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "68", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.blog.sergeykopylov.ru\/pictures\/Screenshot-2020-03-19-at-18.06.46.png", "https:\/\/www.blog.sergeykopylov.ru\/pictures\/Screenshot-2020-03-19-at-18.06.00.png" ] } }, { "id": "16", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/change-your-position\/", "title": "Меняться местами", "content_html": "
Когда мы играли в музыкальной группе, то часто через час репетиции менялись местами. Гитарист — за барабаны, вокалист — за бас, басист за гитару и барабанщик на вокал. Ну или как-нибудь по-другому.<\/p>\n
И так мы играли пару песен. Получалось, конечно, паршиво, но суть не в этом. А в том, что в такие моменты можно лучше понять, что именно делает другой человек в группе, как он это делает, что важно и что нет, а ещё понять, что другие-то тоже нехило так стараются.<\/p>\n
И так, конечно, стоит делать в любом коллективе.<\/p>\n", "date_published": "2020-03-16T19:09:58+03:00", "date_modified": "2020-03-16T19:09:53+03:00", "_date_published_rfc2822": "Mon, 16 Mar 2020 19:09:58 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "16", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } } ], "_e2_version": 3559, "_e2_ua_string": "E2 (v3559; Aegea)" }
- Вы сделали прекрасную историю изменений, которой нет у конкуретнов. Теперь в истории хранится не только время и автор изменения, но и весь слепок версии на то время. Однако, мы боимся, что документы будут меняться часто и история начнёт занимать слишком много места за года использования. На основном сервере мы не можем обеспечить столько места на жёстких дисках, и хотели бы вынести историю в отдельную базу на другом сервере. Можно ли так сделать? Сможете ли вы это запрограммировать?<\/li>\n<\/ul>\n