Об управлении проектами и дизайне

У нас большие новости в Конспекте — мы приступили к работе над совместным редактированием. Эта мегафича даст возможность небольшим командам организовать всю работу над проектом в Конспекте. Прототип дизайна уже давно есть на промостранце:

Для команды Конспекта реализация этой фичи — двойное испытание. Дело в том, что мы первый раз подключаем к разработке внешнюю команду разработчиков — это компания Кортекс:
https://qortex.ru/

Кортексом руководит Коля Митин, с которым я давно знаком, он долгое время был техдиректором бюро.

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

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

Сторонние разработчики раньше не привлекались, поэтому перед началом основных работ мы привели репозиторий с кодом в порядок: обновили и дописали инструкцию по сборке проекта, согласовали стандарты оформления кода, проверили и обновили зависимости в package.json и requirements.txt

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

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

Код бэкенда и фронтенда сильно сцеплен. Это мешает сделать докер-контейнеры для них. Упаковали в контейнер только базу данных.

Бонусом удалось забежать в следующую неделю и собрать докер-контейнер с вебсокет-сервером для совместного редактирования заметок.

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

Будем рассказывать о ходе проекта. А пока — пользуйтесь текущей версией Конспекта. У меня она вообще запинена в браузере, в ней я веду проект по личному росту и проект по развитию одно из продуктов, которым руковожу: https://conspectus.io/

Месяц назад мы решили пивотнуть Конспект и пойти в сторону веб-версии:

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

Изначально мы планировали разместить веб-версию на fff.works/conspectus. Идея была в том, что в будущем Конспект будет лишь одним из инструментов, интегрированных друг с другом в систему, которая сможет закрыть большинство нужд руководителя. 

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

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

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

«Конспект» — заметки на встрече

conspectus.io

Буду очень рад вашим советам и комментам. Пишите в чат:
https://t.me/ffftalks

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

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

Для ребят в состоянии «ничего не случится» приходится нанимать менеджеров (не путать с руководителями), которые будут пинать: «Ну что?», «Ну как?», «Когда?», «Какие препятствия?», «Как я могу помочь?». 

Так и получаются «корпорации» — одни не очень-то спешат работать, потому что, а зачем? А другие их пинают, потому что без этого ваще не работает:

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

А морали в этот раз не будет — каждый сам придумывает, как жить-быть :-)

Несколько месяцев назад Роскомнадзор заблокировал некоторые айпишники Диджитал Оушена. ФФФ-ворксу, конечно, «повезло» и он перестал работать у некоторых провайдеров. 

С одной стороны я надеялся, что РКН одумается, а с другой — не знал, как конкретно всё это исправить. На прошлой неделе терпение лопнуло. Я нашёл ссылку на сайт Глеба Гончарова на странице «Правил русского языка» Бирмана и написал ему:

Глеб очень быстро ответил и предложил план:

В итоге я купил Айхор за 1080 ₽ в год и за пару дней вопрос был решён:

ФФФ.воркс

ФФФ.воркс — это инвентарь руководителя. Проверенные инструменты и приёмы управления проектами, людьми и собой

fff.works

Спасибо Глебу!

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

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

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

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

P. S. А ещё в этом видосе есть прекрасная фраза, с которой начинаются многие инновации: It's not that hard.

P. P. S. Полный видос:
https://www.youtube.com/watch?v=Gk-9Fd2mEnI

По моим наблюдениям в каждом проекте наступает время, когда кажется, что «всё — пиздец». Мол, ничего не получится или получится херня. Обычно это случается ближе к концу проекта, но не в самом конце, где-то на 70% готовности.

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

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

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

Время пиздеца тяжёлое, но если правильно им воспользоваться и не убить проект с горя, наступит время запуска, где уже все будут просто ебашить 🚀🍾🥂

Я всегда стараюсь подсчитывать время честно. Странно же считать, что поход в магазин — это час. Ведь до магазина надо дойти, а потом вернуться обратно. Получается не час, а 2,5. 

Или перелёт на самолёте. Это не 3,5 час, потому что до и после прибавляется по полтора — два часа на дорогу.

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

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

Так что сегодня мой календарь дел выглядит так:

P. S. О календаре дел:
http://fff.works/blog/all/task-calendar/

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