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

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

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

Новый фрагмент книги рассказывает о зарождении кооперативного движения, первых — умопомрачительных — сделках по продаже софта и основании «Микроконтура», из которого и вырастет потом «Параграф».

Главный герой этой главы — известный программист Антон Чижов.

Фото 1992-го года из журнала «Мир ПК»

Технически в книге — это четвертая глава, через одну после опубликованной две недели назад. В предшествующей речь идет о том, как Степан Пачиков при помощи Гарри Каспарова и вице-президента Академии Наук Евгения Велихова организовал в Москве детский компьютерный клуб. Благодаря этому клубу он обзавелся множеством новых знакомств в компьютерной тусовке.

Это любопытный сюжет, но его пока пропустим. Мне хочется сразу перейти к описанию событий, которые, как мне кажется, будут особенно интересны на «Хабре»: зарождению кооперативного движения и образованию первых компьютерных фирм.

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

Поехали!

То, что их интересно решать, не означает, что они кому-то нужны

«Группа людей проводит мозговой штурм над ноутбуком и листом бумаги», фото Стефана Стефанчика с Unspalsh

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

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

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

Закон Амдала

В 1967 году Джин Амдал представил довод против параллельных вычислений. Он утверждал, что рост производительности ограничен, поскольку только часть задачи поддаётся распараллеливанию. Размер остальной «последовательной части» отличается в разных задачах, но она есть всегда. Этот довод стал известен как закон Амдала.

Если построить график «ускорения» выполнения задачи в зависимости от количества выделенных ей параллельных процессоров, вы увидите следующее:


Это асимптотический график для фрагмента, который не поддаётся распараллеливанию («последовательная часть»), поэтому существует верхний предел максимального ускорения

Нам пишут:
«Хм, а дайте плиз совет.

Реальный кейс, три разработчика, один разработчик работает 100% времени удаленно, второй разработчик — шеф/соучредитель, третий — немного офигевающий новоприбывший.

Общие совещания — раз в полгода и дальше слов дело не идет. Внедрить GIT для всех разработчиков не получается, все завалены текущей работой.

Есть ли способы как-то улучшить ситуацию?»

У нас юбилей — на хабраблог Яндекс.Денег подписалось 500 человек. В честь этого запускаем экспериментальную рубрику — берём вопрос одного из читателей, связанный с рабочей ситуацией, и бережно передаём его коллегам из Яндекс.Денег, которые знают жизнь. О сегодняшнем вопросе некоторые подумали, что я их разыгрываю и специально придумал такую странную ситуацию. Удивительно, но нет.

На практике мы часто сталкиваемся с тем, что руководитель проекта хочет ускорить процесс разработки — его не устраивает скорость поставки нового функционала. Как правило такие клиенты нуждаются в сложных продуктах вроде системы управления госпиталем, системы торговли на бирже, банковских системах, ДБО.

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

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

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

Приветствую всех! Я работаю в Департаменте информационной безопасности ЛАНИТ, руковожу отделом проектирования и внедрения. В этой статье я хочу поделиться опытом, как на старте карьеры совсем в другой компании подготовил стандарт для организации защиты персональных данных в медучреждениях. Это история о том, как написать 500 страниц с нуля за 10 дней, сделанных ошибках и сложностях, которые не были преодолены. Надеюсь, мой опыт поможет всем, на кого свалилась задача написать руководящий документ, стандарт или закон.

Источник

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



Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.

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

Многие другие крупные IT-компании, начиналась со стартапа, и Badoo не исключение. За последние годы компания прошла путь от нескольких десятков инженеров до нескольких сотен. Николай Крапивный был на передовой на большей части этого пути и принимал решения: что лучше делать, а что не делать, как справляться с проблемами. Его доклад на TeamLead Conf был посвящен этому опыту и картине мира, которая в результате сформировалась.

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



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

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

Несколько лет назад, в связи с выходом на американский рынок, стратеги Компании просчитали риски и сочли использование нелегального ПО абсолютно неприемлемым. Основная масса ПО производилась Правообладателем. Перед ИТ-службой была поставлена задача стать «белыми и пушистыми» (С) — ген. директор. Задача осложнялась тем, что ИТ-службе требовалось не только обеспечить чистоту ПО, но получить от Правообладателя «всем бумажкам бумажку» (С) — Ф.Ф. Преображенский. Такой документ, чтобы никакой проверяющий сторонний орган не мог огульно обвинить Компанию в нон-комплайнсе и Компании не пришлось доказывать обратное, в то время как риски срабатывают.

В прошлом году к нам обратился ИТ-директор одного из крупнейших аграрно-промышленных холдингов в России. Подход к бизнесу, который реализовал наш клиент, был впечатляющим. Он одним из первых реализовал идею предприятия полного цикла – от поля до полки в продуктовом магазине. Благодаря доступности и высокому качеству продукции этот холдинг стал признанным брендом, который знают и выбирают. В тот момент в холдинг входило более 650 торговых точек и более 20 000 сотрудников, распределенных по всей территории РФ.

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

С учетом указанной специфики решение задачи превратилось в увлекательное приключение с бубном, шаманами и кроличьими лапками в лице RabbitMQ. Как мы строили федеративный кластер очередей и с чем столкнулись – под катом.

Какой вообще смысл в этих ретроспективах?

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

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

Это просто.

Смысл работы скрам-мастера (или Agile-коуча) в создании и развитии эффективной команды. Причем основным развиваемым качеством команды должна быть самоорганизация.
По сути для проведения успешных ретроспектив вы как скрам-мастер должны знать две вещи:

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

Современное развитие IT технологий позволило обуздать громадные потоки данных.
У бизнеса появились различные инструменты: CRM, ERP, BPM, бухгалтерские системы или в крайнем случае просто Excel и Word.

Компании тоже бывают разные. Некоторые, состоят из множества обособленных филиалов. В таком случае у бизнеса возникает проблема синхронизации данных в зоопарке IT систем. Тем более, что у филиалов отличаются вендоры или версии ПО. А частые изменения требований к отчётности от управляющей компании вызывают приступы неконтролируемой “радости” на местах.

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

Или делайте это правильно

Если выбрать одну идею, которая убивает больше всего продуктов, то это создание запаса на будущее (future proofing).

Обычно идея проявляется по схеме.

Нам нужен {X}, и хотя сделать {Y} гораздо легче, но при наступлении {Z} первый вариант упростит нам жизнь.

Где {Z} — событие, которое может произойти в далёком будущем.

Вот несколько примеров:

• Для инфраструктуры нужны Kubernetes и Docker, хотя один большой сервер гораздо проще, но когда придётся масштабироваться до 11-ти серверов, это упростит нам жизнь.
• Для обработки данных нужен распределённый дизайн, хотя централизованное решение гораздо проще, но когда клиент потребует 99,999% безотказной работы в SLA, это упростит нам жизнь.
• Нужно набрать команду разработчиков и создать собственное программное обеспечение, хотя Wordpress и Shopify гораздо проще, но когда клиентская база вырастет в 100 раз, это упростит нам жизнь.
• Нужно использовать дизайн на основе наследования типов, хотя композиция гораздо проще, но после 5 лет увеличения кодовой базы это упростит нам жизнь.
• Нужно написать код в C++ с кэшированием представлений, хотя Python-скрипт с прямыми запросами к Postgres гораздо проще, но при большом увеличении объёма данных это упростит нам жизнь.

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

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

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

• Как команда технарей свою студию создавала. Опыт первых месяцев. Достижения, фейлы, умозаключения…
• Как команда технарей свою компанию создавала, сезон 2 (жизнь в кризис)

Иной раз чудится, что тимлид — это кто-то или что-то вроде Снарка из поэмы Льюиса Кэрролла: точно существует, разносторонне и противоречиво описан в своих бытовых и деловых проявлениях, но при всем при том что представляет собой — загадка. Разобраться с тем, насколько значима эта (тимлида, не Снарка) роль в инженерных командах, кого правильнее на нее ставить и какие подводные камни скрыты в «тимлидстве», обещает помочь Saint TeamLead Conf 2018, которая пройдет 24–25 сентября в Санкт-Петербурге.

За месяц до мероприятия мы без лишних формальностей поговорили с техническим директором проекта Mos.ru Романом Ивлиевым, который возглавляет Программный комитет Saint TeamLead Conf 2018. В беседе: кто такие тимлиды, как их правильно готовить, кого и к чему должны готовить они, каким должен быть круг их обязанностей и многое другое.

Мы публикуем перевод материала Александра Савченко, сотрудника компании Django Stars. Он рассказывает, как оценивать стоимость создания мобильных приложений, учитывая как прямые, так и косвенные статьи расходов.

Определение стоимости разработки конкретного приложения — важная задача как для компании, так и для программиста, который работает самостоятельно. Сразу стоит сказать, что 100%-ной точности достичь вряд ли получится, но этот обзор поможет приблизиться к максимальной корректности оценки.

Предисловие

«У нас приемлемый уровень брака!» именно с этой фразы начинается общение почти с каждым директором по качеству на производственных предприятиях в России. Многие из них даже будут уверять, что добились качества мирового уровня в виде 3,4 бракованных изделий на 1 000 000 произведенных. Да и в целом на всех профильных форумах и конференциях мы слышим, что в России лучшее качество в мире, а все остальные страны нам завидуют.

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

Во времена СССР качество достигалось за счет полного и непрекословного соблюдения всевозможных ГОСТов. Но, к сожалению, в наших реалиях соблюдение ГОСТов не является приоритетным требованием (за исключением предприятий ВПК), а главная цель производства — сделать все быстрее и дешевле. Исходя из этого тезиса у нас активно внедряются методы оптимизации в виде инструментов Lean и сокращается персонал при увеличении объемов производства.

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

Для начала достаточно ответить на два простых вопроса:

• Зачем это мне?
• Что я расскажу интересного и полезного хабраобществу?

После чего можно взять план из этой статьи (или придумать свой) и сделать это.


Есть творческие этапы и технические. В этой статье поговорим о творческих. Рассмотрим:

• Зачем писать статьи,
• Откуда взять тему для статьи,
• Где найти время, чтобы её написать,
• Основные этапы работы над текстом,
• Что делать, если статья «не идёт»,
• И с чего начать, если ты ни разу не писал на Хабр.

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