Управление проектами *

Всем снова привет!

Вроде бы еще не так давно я рассказывал, как выглядит обмен знаниями в Exness глазами новичка, и вот уже снова есть, что рассказать!

На самом деле, гибкость и скорость это два больших плюса в любом бизнесе. И на работу knowledge manager’a это влияет в огромной степени.

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

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

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

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

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

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

Привет, Хабр! Наша команда занимается мониторингом станков и разных установок по всей стране. По сути, мы обеспечиваем возможность производителю не гонять лишний раз инженера, когда «ой, оно всё сломалось», а на деле надо нажать одну кнопку. Или когда сломалось не на оборудовании, а рядом.

Базовая проблема следующая. Вот вы производите установку для крекинга нефти, либо станок для машиностроения, либо какое-то другое устройство для завода. Как правило, продажа сама по себе крайне редко возможна: обычно это контракт на поставку и обслуживание. То есть вы гарантируете, что железяка будет работать лет 10 без перебоев, а за перебои отвечаете либо финансово, либо обеспечиваете жёсткие SLA, либо что-то подобное.

По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.

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

А ведь в прошлом году это делали senior-разработчики.

Возможно, вы помните, что мы говорили про то, как можно сильно улучшить работу обычного сельскохозяйственного комбайна, если использовать нейросетки для распознавания культур и препятствий и робота для автопилотирования. Всё это (кроме процессоров Nvidia и ещё части железа) — наша разработка. А радость в том, что в некоторых южных регионах страны закончилась уборочная страда, и наши комбайны показали себя лучше, чем ожидалось. Слава роботам!



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

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

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

Две недели назад, на форумах обнаружили базы данных 600 тысяч клиентов сервисов Avito и Юла, среди которых фигурируют реальные адреса и номера телефонов. Базы до сих пор размещены в свободном доступе, их может скачать любой желающий. А представьте сколько человек уже скачало базу с умыслом разослать спам или, что еще хуже, выманить данные платежных карт пользователей. Администрация форумов не удаляет базы, так как

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



В ЦФТ эту проблему решили регулярные встречи с инженерами один на один. Встречи помогают: вовремя выявить проблемы в работе, профессионально развиваться, повышать мотивацию и находить новые смыслы. О том, как готовиться ко встречам, какие вопросы задавать и как регулярно их проводить, расскажет Михаил Емельянов. Теперь вы будете знать, что делать, если инженер сказал: «Нам нужно поговорить...»

Михаил Емельянов — Head of Android Department в ЦФТ. В IT-разработке 12 лет, с Android — 10, из которых 2 года руководит командой Android-разработки в ЦФТ. Разрабатывал проект мультимедиа, различные проекты в финтехе и запускал стартапы.

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

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

Вы изучили команды Git но хотите представлять, как непрерывная интеграция (Continuous Integration, CI) происходит в реальности? Или может вы хотите оптимизировать свои ежедневные действия? Этот курс даст вам практические навыки непрерывной интеграции с использованием репозитория на GitHub. Данный курс не задуман как некий визард, который можно просто прокликать, напротив, вы будете совершать те же действия, что люди на самом деле делают на работе, тем же способом, которым они это делают. Я буду объяснять теорию по мере прохождения вами имеющих к ней отношение шагов.

Что мы будем делать?

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

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

Вы пройдёте такие стандартные для CI сценарии:

• Работа над фичей;
• Применение автотестов для обеспечения качества;
• Реализация приоритетной задачи;
• Разрешение конфликта при слиянии ветвей (merge conflict);
• Возникновение ошибки в продуктивной среде.

Не мечта ли любого владельца компании управлять IT-продуктом так, чтобы поставлять продукт в срок, обгоняя конкурентов, и делать это с высоким качеством, радуя пользователей? Хотелось бы найти серебряную пулю для управления и, кажется, она есть. Не такая уж серебряная и не такая уж пуля, но довольно надежный и обкатанный годами подход к управлению, который можно назвать FFF: Fix Time and Budget, Flex Scope.

Почему и когда стоит выбрать FFF? Давайте посмотрим.

Это истории тех, кто учится в «Школе 21», успешно прошёл стажировку и остался работать в Сбербанке. Я уже рассказывала, что этот проект — путь в IT и он крайне эффективен. Если очень коротко — мы научились готовить джунов с нуля за год, делая упор на soft skills. Учиться нужно умению мыслить как разработчик — от анализа требований до взаимодействия внутри команды. Что, собственно, в «Школе 21» и происходит на базе C, где ребята в полубоевых условиях работают над проектами не по учебному материалу, а ищут всю информацию сами. Не все верят, что люди после такой подготовки могут быстро освоить новый язык или фреймворк за время стажировки и начать работать разработчиком.

Могут. Вот истории четырёх участников «Школы 21», которые прошли как раз такой путь.

Русфинанс Банк — это лидер по автокредитованию в России (по версии Frank RG), который входит в международную группу Société Générale. С одной стороны, мы можем смотреть на опыт разных стран, применять инструменты, которые используют наши коллеги не только во Франции, но по всему миру, с другой — для нас разработка и запуск любого нового ИТ-продукта, сервиса и даже фичи — это всегда челлендж, в том числе связанный с разными уровнями согласования проектов.

В своё время, в попытке сократить time-to-market, нам удалось попробовать и внедрить разные Agile-практики. Что ожидаемо, самой жизнеспособной из них оказался SCRUM.

В начале 2020 года мы начали масштабировать SCRUM, изучили фреймфорк LeSS и выстроили процессы взаимодействия офлайн, но пандемия внесла свои коррективы: в марте нас перевели на удалённый формат работы. Пришлось всё экстренно перестраивать.

Под катом мы расскажем о том, какие задачи нам пришлось решить, как в этом нам помогли инструменты SCRUM и LeSS и что из этого получилось.

Если вы не зарегистрированы на hh.ru или подобных ресурсах, находите работу в профильных сообществах на Facebook, в Telegram и по «сарафанному радио», и у вас нет отбоя от предложений, вам не нужно резюме. Но обычно оно нужно тем, кто вас нанимает — с рекрутера или HR начинается первый контакт разработчика и работодателя. Они изучают резюме кандидата перед тем, как передать его техническим специалистам и нанимателю. Рекрутер и HR — это первый этап отбора во всех компаниях, начиная с провинциальной веб-студии и заканчивая Яндексом или Сбербанком. Важно быстро пройти этот этап, а чтобы это сделать и нужно хорошее резюме.



Мы в headz.io работали примерно с 5000 резюме тестировщиков, разработчиков, DevOps-инженеров и других IT-специалистов, чтобы помочь им устроиться на ту работу, которую они хотели. Поэтому можем рассказать, как подготовить резюме, чтобы быстро пройти рекрутера или HR и понравиться работодателю.

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

Конечно, пока за рубежом cloud-сервисами пользуются активнее, чем в России. По данным Gartner, в 2019 года мировой рынок публичных облаков составил $242,7 млрд, а в нашей стране – пока 73 млрд рублей (~$1 млрд), следует из отчета «ТМТ Консалтинг», хотя в России этот рынок растет быстрыми темпами.

Наши международные клиенты уже пользуются решениями, которые работают в облаке, например, ABBYY FlexiCapture и Cloud OCR SDK. Они помогают заказчикам автоматически распознавать штрихкоды, извлекать из товарных накладных суммы и даты и многое другое – и делать все это со всевозможных устройств, различных операционных систем, удобно и безопасно. Нам бы хотелось, чтобы наши интеллектуальные решения становились еще доступнее для пользователей. Ведь даже в пандемию компаниям во всем мире все равно нужно обрабатывать счета, готовить налоговую отчетность, сравнивать написанное мелким шрифтом в разных версиях кредитных договоров, а также внедрять решения для удаленного обслуживания клиентов. Чтобы все эти задачи можно было решить в любое время, где угодно и в необходимом объеме, мы взяли курс на интеграцию наших продуктов с облачными технологиями.

Именно поэтому в 2019 году в нашей команде появился главный архитектор – человек с хорошим знанием подходов к созданию архитектуры программного обеспечения в компании сегмента B2B и с большим опытом в построении и развитии облачных сервисов. Им стал Владимир Юнев, в прошлом – облачный архитектор и эксперт по стратегическим технологиям Microsoft, известный в сообществе на Хабре как @XaocCPS.

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

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

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

Однажды, дегустируя новое пиво, мы с моим знакомым поспорили о том, что такое цифровая трансформация. Мой знакомый утверждал, что эта цифровая трансформация — просто пустое слово, под которое удобно выделять деньги. Мол, приходят CDTO (Chief Digital Transformation Officer, не смейтесь, это действительно так называется), берут огромные деньги, внедряют пару систем цифровой документации и какое-нибудь новшество на производстве, и все, мы вам трансформировали, давайте, растите.



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

— И что, спрашивает мой знакомый, прям любого бизнеса?
— Да, любого-любого, отвечаю я.
— А, ммм… даже общественной бани?

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

В далекой-далекой галактике трудится сферический product owner. Он бегло пишет заметки на салфетке и молча отдает ее разработчикам. А вскоре получает готовый продукт, который на 100% соответствует его ожиданиям. Даже если продукт этот – сложный кроссплатформенный сервис с блэкджеком и адаптивностью.

Возможно ли такое на практике?

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

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

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