Рубрика «процессы» - 2

в 19:00, , рубрики: Блог компании Playgendary, процессы, работа из дома, распределённая команда, удалёнка, удаленная работа, управление персоналом, Управление продуктом, управление проектами, управление разработкой

В офисе никого: разработка игр на удаленке - 1

Дисклеймер. У нас нет «удаленных» сотрудников — в команде все равноудалены друг от друга. Просто кто-то работает (сейчас правильнее сказать «работал») в офисе, а кто-то дома или в коворкинге. Поэтому внутри мы предпочитаем термин «распределенная команда».

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

У нас много команд занимающихся разработкой продуктов — есть и по 10 человек, и по 40-50 — но нет ни одной, где все ребята сидели бы рядом в офисе. Зато есть команды, которые полностью работают из дома. Из-за последних событий на «домашний режим» перешли вообще все, но пандемия практически не повлияла на процессы, потому что всё было выстроено заранее.

Дальше — несколько больших разделов о внутренней кухне: онбординг, коммуникации и работа с командой, обмен опытом. А для разнообразия разбавим текст фотографиями наших «домашних офисов». Читать полностью »

в 8:39, , рубрики: devops, Блог компании Playgendary, инструменты, методология, процессы, системное администрирование, управление персоналом

Кто такой DevOps и когда он не нужен - 1

Тема DevOps за последние несколько лет стала очень популярной. Некоторые мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.

Многие указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом» с зарплатой 300к/нс. Это, конечно, не так.
Читать полностью »

в 13:17, , рубрики: Блог компании Wrike, Проектирование и рефакторинг, процессы, технический долг, управление проектами, управление разработкой

Звездолеты на ДВС. Выжить в схватке с техническим долгом - 1

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

в 9:04, , рубрики: Блог компании Lamoda, процессы, тимлиды и разработчики, управление командой, управление персоналом, Учебный процесс в IT

Всем привет! Меня зовут Александр Афенов, я тимлид команды Order Processing в компании Lamoda. Сегодня я хочу вам рассказать о практиках обмена знаниями: какие проблемы эти практики решают, как мы к ним пришли, и как они влияют на жизнь разработчика.

image

Читать полностью »

в 11:00, , рубрики: python, Блог компании Open Data Science, глубинное обучение, графовые сверточные сети, графы, инновации, кадровые перестановки, математика, машинное обучение, мода, модели, организационные структуры и потоки, проекты, процессы, трансформации, тренды, управление, управление персоналом, Управление продуктом

75%

3 из 4 — так Boston Consulting Group оценивает долю IT проектов, почивших по не-техническим причинам.

Уже вот две подряд редакции свода знаний по управлению проектами (PMBOK) выделяют процессы по управлению стейкхолдерами в отдельную область знаний под счастливым номером 13 и настоятельно рекомендуют учитывать:

1. связи между ними,
2. центры влияния, а также
3. культуру общения — для повышения шансов на успех.

Вопрос один:

 доколе инженеры о стейкхолдерах будут судить догадками?

image

ФОТО: Шариф Хамза для Dazed & Confuzed, модель — Люпита Нионго

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

Читать полностью »

в 8:12, , рубрики: best practices, fallback, post mortem, безопасность, Блог компании FunCorp, валидация, высокая производительность, кеширование, надежность, оптимизация, прагматизм, практики, практики программирования, Программирование, Проектирование и рефакторинг, процесс разработки, процессы, Разделение привилегий, разделяй и властвуй, разработка, Совершенный код, стабильность
Программист-защитник сильнее энтропии - 1

© Dragon Ball. Goku.

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

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

Давайте разберёмся подробнее, что входит в понятие «падать изящно».

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

Читать полностью »

в 9:39, , рубрики: Блог компании FunCorp, качество, качество кода, код, мартин фаулер, Программирование, процессы, разработка, Совершенный код, Управление продуктом, управление разработкой
Стоит ли высокое качество ПО затрат на его разработку? - 1

Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.

Закон Беттериджа гласит: «На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет». Те, кто знаком со мной лично, знают, что я не разделяю эту мысль. Но в этой статье я хочу пойти ещё дальше и доказать, что постановка вопроса из заголовка этой статьи просто не имеет смысла. Такая постановка вопроса предполагает, что существует компромисс между затратами и качеством. И необходимо постоянно соблюдать баланс. В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.

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

в 8:09, , рубрики: Блог компании Яндекс, Карьера в IT-индустрии, конференции, митап, процессы, управление персоналом, управление разработкой

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

Когда-то я был младшим разработчиком и ужасно не любил слово «процессы». Все эти регулярные встречи и прочее общение казались глупостями, отвлекающими от содержательной работы (написания кода, конечно). Думаю, такой этап случался в жизни у каждого, кто занимался разработкой; но такому этапу полезно повторяться регулярно: любую деятельность можно оптимизировать (например, вообще отменив), и иногда ощущение бессмысленности происходящего оказывает поистине целебное действие.

Как устроены процессы разработки в различных компаниях - 1

Мы решили посвятить процессам разработки наш следующий Team Leader Meetup, который пройдёт вечером 17 июня в московском офисе Яндекса. Регистрация открыта!

Нашими экспертами согласились быть:

  • Анатолий anatolix Орлов, CTO, Ozon
  • Алексей Катаев deusdeorum, Head of Software Development, SkyEng
  • Александр Гутман, CTO, JoomPay
  • Евгений Парамонов, руководитель разработки поисковых подмешиваний, Яндекс
  • Андрей Плахов yafinder, руководитель отдела функциональности поиска, Яндекс

Сегодня они отвечают на некоторые вопросы, чтобы подготовить будущую дискуссию:

1. На какой основе построены процессы у вас в компании?
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»

Под катом — много огня, сарказм в адрес авторов вопросов, максимально различные мнения и, конечно, страшные истории.

Читать полностью »

в 15:01, , рубрики: Elixir, erlang, let it crash, без регистрации и смс, даром, для всех, конкурентность, параллельное программирование, Программирование, Проектирование и рефакторинг, процессы, Совершенный код, счастья, функциональное программирование

Введение от переводчика

В данной статье речь идёт об Erlang, но всё сказанное в равной степени применимо и к Elixir — функциональному языку, работающему поверх той же виртуальной машины BEAM. Он появился в 2012 году и сейчас активно развивается. Elixir получил более привычный большинству синтаксис плюс обширные возможности метапрограммирования, сохранив преимущества Erlang.

Ещё от переводчика

Статья от 2016 года, но речь в ней идёт о базовых концепциях, которые не устаревают.

Ссылки на понятия и комментарии от меня (переводчика) расположены в квадратных скобках [] и снабжены указателем "прим. переводчика".

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

Отдельное спасибо Яну Гравшину за помощь в вычитке и редактуре текста.

Это свободная расшифровка (или долгий парафраз?) моей презентации на организованной Genetec конференции ConnectDev'16.

001

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

Читать полностью »

в 13:07, , рубрики: ABBYY, android, bcr, business card reader, finescanner, iOS, ml, textgrabber, Блог компании ABBYY, вакансии, Карьера в IT-индустрии, команда, мобильные приложения, Офисы IT-компаний, процессы, разработка мобильных приложений, управление персоналом

image

Здравствуй! В далёком 2005 году в ABBYY появился первый мобильный SDK. А в 2007 в компании образовался отдельный департамент ABBYY Mobile, и начали рождаться технологии, которые стали основой наших приложений — ABBYY Business Card Reader, ABBYY FineScanner и ABBYY TextGrabber. В 2009 наш первопроходец Business Card Reader вышел на мобильные (кнопочные!) телефоны Nokia под управлением Symbian. И совсем скоро, 19 марта 2019 года, мы будем праздновать первое десятилетие.

В этом посте мы расскажем и покажем, как устроена изнутри жизнь и работа ABBYY Mobile, какие технологии мы разрабатываем, куда ездим в командировки и многое другое.
Читать полностью »

123...5
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js