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

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

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

Разговор в автомобиле на трассе из Дубая в Шарджу 31 июля 2020 года:

- Город-стройка. Сколько всего возводят … Но для кого? Кто будет здесь жить? Тем более после такого кризиса. Дубай экспо переносят, резиденты покидают страну, многие потеряли работу или бизнес: даже авиакомпания Эмирейтс сократила тысячи сотрудников, в число которых попал мой друг пилот.

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

Заголовок в новостях 31 января 2021 года, ровно спустя семь месяцев:

«ОАЭ впервые в истории предоставляет иностранцам право получить гражданство».

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

Для решения такой задачи было создано очередное решение под названием Trigger Hook. Принципиальная схема работы показана на рисунке 1. На схеме показано, что происходит с заданиями в течения всего их жизненного цикла. Смена цвета означает смену статуса задачи.

Нередко при работе с Bitrix24 REST API возникает необходимость быстро получить содержимое определенных полей всех элементов какого-то списка (например, лидов).

Традиционный способ для этого - обращение к серверу через метод *.list (например, crm.lead.list для лидов) с параметром select, перечисляющим список требуемых полей. При этом, чем больше полей вы запрашиваете, тем больше времени серверу требуется для формирования ответа. Плюс, в силу того, что информация сервером выдается постранично, получение всего списка через последовательные запросы всех страниц может занимать много времени.

Однако существует несколько стратегий для того, которые позволяют ускорить процесс на порядки.

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

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

Меня зовут Павел Комаровский, и я алкоголик занимаюсь саморазвитием уже более 10 лет. Эта статья о том, какой подход к личному целеполаганию я выработал для себя в итоге – надеюсь, она поможет вам избежать ошибок, которых в своё время наделал я.

Я полностью прошёл все стадии грехопадения: в студенческие годы искал сакральные ответы в стопках self-help макулатуры; затем разочаровался и решил, что весь этот «успешный успех» – это разводилово для дурачков (до сих пор уверен, что Наполеон Хилл – шизофреник); позже переосмыслил всё ещё раз и пришёл к своему пониманию того, как может выглядеть саморазвитие с адекватным лицом.

Отрицание

1. В модулях должны работать типы typescript
2. Модули должно быть легко использовать в компонентах, должны работать типы для стейта, экшенов, мутаций и геттеров
3. Не придумывать новое api для vuex, надо сделать так, чтобы как-то типы typescript заработали с модулями vuex, чтобы не приходилось разом переписывать всё приложение
4. Вызов мутаций и экшенов должен быть максимально простым и понятным
5. Пакет должен быть как можно меньше
6. Не хочу хранить константы с именами мутаций и экшенов
7. Оно должно работать (А как же без этого)

Сборщики меди

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

• Проверка каждой ветки проходила локально. Приходилось откатывать базу от изменений с предыдущей проверки, билдить фронт. Когда несколько разработчиков вот-вот закончат работы и осталось проверить каждую по мелочи — это превращалось в ад;
• Различались окружения на проде и между разработчиками, что приводило к ошибкам: “у меня всё работает”.

Внутренний перфекционист жаждал организовать всё правильно. Делюсь результатами поисков ответа на вопрос: «а как, собственно, “правильно”»?

Мы добились

• Легкого и быстрого деплоя в production (ради эксперимента выводили каждый день две недели подряд);
• Гарантию защищённости от ошибок из-за различий в окружении приложения;
• Можем организовать эффективное взаимодействие с заказчиком:
  
  • демонстрировать каждую feature-ветку;
  • давать гостевой доступ для создания задач и наблюдения над ходом работ.

Данная статья будет полезна, если вы:

• начинающая IT-компания или в первый раз столкнулись с работой в команде над большим проектом;
• хотите обновить свой устаревший процесс разработки (workflow);
• ищете лучшие практики и хотите посмотреть, как у других;
• часто натыкаетесь на статьи про DevOps, CI/CD, облака и хотите, чтобы у вас одним нажатием кнопки создавались тестовые окружения, а очередное обновление прода не было рулеткой.

Под катом вы найдёте

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

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

Все что нужно - любой хостинг, или бесплатные тарифы Heroku/AWS и т.д.