Все потоки
Поиск
Написать публикацию
Обновить
242.72

Управление разработкой *

Планирование, отслеживание и контроль

Сначала показывать
Порог рейтинга
Уровень сложности

В двух словах о NEXUS

Время на прочтение4 мин
Количество просмотров78K
Весной этого года команда наших разработчиков побывала на тренинге по многокомандному скраму с использованием фреймворка Nexus. Это оказался очень интересный инструмент, и мы хотим поделиться с вами впечатлениями от его возможностей.


Читать дальше →

Как чат-боты постепенно исключают человеческий фактор в российском банковском секторе

Время на прочтение5 мин
Количество просмотров15K
imageВ эпоху стремительного развития социальных сетей и мессенджеров, финансовые компании и банки, как и другие бизнесы, стали активно использовать данные каналы коммуникации для взаимодействия с клиентами, при этом не преминув оптимизировать свою работу с помощью чат-ботов. Мы, в процессинговой компании PayOnline решили рассмотреть актуальные тенденции и предложить вниманию хабравчан наиболее интересные кейсы использования технологии виртуального собеседника в российском финансово-банковском секторе.
Читать дальше →

Когда стоит задуматься об оптимизации ИТ-инфраструктуры?

Время на прочтение7 мин
Количество просмотров5K
image


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

Читать дальше →

Программировать скучно, но…

Время на прочтение8 мин
Количество просмотров47K

Оригинал: Bruno Marnette: Coding is boring, unless…


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


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


(Оговорка: мне везло, что я жил в местах, где работы для программистов было больше, чем программистов! Я понимаю, что возможность сменить работу доступна не всем).


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


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


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


Вот почему мы заранее предлагаем решение, создавая культуру, которая спасет нас (постучим по дереву!) и сделает так, чтобы никогда не становилось скучно.

Читать дальше →

Самые дорогие и судьбоносные ошибки в ИТ-индустрии

Время на прочтение8 мин
Количество просмотров87K


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

Первый баг был зафиксирован 9 сентября 1945 года: в вычислительной машине Mark II Aiken Relay Calculator нашли мотылька, застрявшего между контактами электромеханического реле, что приводило к ошибкам. Извлеченное насекомое было вклеено в технический дневник с сопроводительной надписью: «First actual case of bug being found». Этот забавный факт и положил начало использованию слова «баг» в современном значении.
Читать дальше →

Un-FuckUp-able Development Protocol (UDP)

Время на прочтение8 мин
Количество просмотров14K
Недавно после очередного Team Building’a получил от одного Коллеги-Графомана письмо-притчу про большую кнопку «сделать всё хорошо». Он и раньше баловался изобретением велосипедов, но в этот раз конструкция показалась мне на редкость удачной. Кому интересно — прошу-приглашаю под кат. С его разрешения дословно:

В эту сиесту на веранде практически никто не курил, потому, что все ушли на очередной двухдневный SCRUM-тренинг. Джонни устало окинул взглядом присутствующих: Дёму и Варю. Они тоже не были в восторге от происходящего, было слишком жарко и душно, лето в Долине было в самом разгаре, и казалось, что на улице даже жарче чем в Task Tracker’е.


Читать дальше →

Техническое задание на доработку: 10 правил и немного занудства

Время на прочтение14 мин
Количество просмотров121K
Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.


Читать дальше →

Кого волнуют баги продукта, если он успешно продается

Время на прочтение6 мин
Количество просмотров23K

Изображение сайта media.licdn.com

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

По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.

Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений. Зато очевидным преимуществом этих компаний является удачная бизнес-модель. Вкупе с активным продвижением, эти сервисы смогли стать одними из самых востребованных и дорогих стартапов мира. Но вряд ли они нанимали десятки инженеров, чтобы разработать сервис и подготовить его к запуску, сомневается Половетс.
Читать дальше →

Что иметь в виду при переписывании программного обеспечения

Время на прочтение3 мин
Количество просмотров13K

При разработке каких-либо продуктов у команды зачастую возникает желание перестать бороться с текущим состоянием проекта и переписать всё снова, на этот раз "правильно" и "по науке". Обычно такие порывы не одобряются, но в этот раз я бы хотел предложить к прочтению перевод поста Hugo Baraúna, посвященного тому, какие вопросы нужно задать себе, если всё же решили переписывать.


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


Будут ли обе платформы существовать одновременно, или нет?

Читать дальше →

«Бег с препятствиями»: Повышаем эффективность разработки сервисов

Время на прочтение5 мин
Количество просмотров4.1K


Фото Paul CC

Занимаясь разработкой IaaS-провайдера, мы в 1cloud не понаслышке знаем о том, как важно грамотно организовать рабочий процесс всей команды. Недавно мы публиковали материал, в котором обсудили 13 вещей, которые не стоит говорить разработчикам и тестировщикам, а в другом посте затронули тему корпоративной культуры организаций.

Сегодня нам бы хотелось вновь углубиться в область организации процессов компании и поговорить о том, как оптимизировать разработку сервисов.
Читать дальше →

О роли DevOps в ИТ — мнения экспертов

Время на прочтение7 мин
Количество просмотров30K

Изображение сайта tricentis.com

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

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

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

Когда разработчику вредно совмещать программирование и техническую поддержку ПО

Время на прочтение6 мин
Количество просмотров16K

Изображение сайта easywebstudio.ru

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

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

Как не выбить разработчика из состояния «потока»

Время на прочтение3 мин
Количество просмотров16K


/ фото Rachel Johnson CC

Время разработчика – это бесценный ресурс, которого постоянно не хватает. Мы в компании «ИТ-ГРАД» относимся к этому вопросу очень внимательно.

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

В связи с этим мы хотели бы дать несколько советов для руководителей компаний и менеджеров проектов, которые позволят максимально эффективно работать и взаимодействовать с командой разработки.
Читать дальше →

Ближайшие события

Человеческий фактор остается самым сильным, но выгодным риском в разработке ПО

Время на прочтение6 мин
Количество просмотров13K

Изображение с сайта projectimo.ru

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

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

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

Как Линус Торвальдс сделал разработку ПО свободнее

Время на прочтение6 мин
Количество просмотров25K


«Я делаю свободное ПО, потому что считаю это единственным правильным способом разработки»

Некоторые считают Линуса Торвальдса, создателя операционной системы Linux и репозитория Git, просто везучим человеком. Кому-то он, наоборот, кажется целеустремленным энтузиастом своего дела. Однако никто не будет спорить с тем, что благодаря исключительной одаренности Торвальдса появилась операционная система, которая распространилась по всему миру.

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

С 18 июля новый порядок регистрации программ для ЭВМ в Роспатенте. Что изменилось?

Время на прочтение6 мин
Количество просмотров74K
18 июля 2016 года вступили в силу новый Административный регламент предоставления государственной услуги по государственной регистрации программы для ЭВМ, а также новые Правила регистрации программ и баз данных. Таким образом, прекращает действие Административный регламент 2008 года. Понятно, что если вы по каким-то причинам регистрируете программы в Роспатенте (зачем их регистрировать — мы обсуждали здесь ранее), то с 18 июля нужно пользоваться новой формой заявления.



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

Недалекое прошлое: этюд о проблемах автоматизации тестирования

Время на прочтение6 мин
Количество просмотров11K

Изображение с сайта familyexpert.ru

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

Хотя самому факту автоматизации тестирования в прогрессивных компаниях СНГ можно было найти подтверждение, но это подтверждение, на поверку, оказывалось формальным. Как говорится, и «да, и нет». По крайней мере, так было несколько лет назад.
Читать дальше →

Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS

Время на прочтение22 мин
Количество просмотров27K

BPM «Как есть» и «как не есть»


Продолжаем размышлять «что такое BPM», это который «Business Process Management» и какие они бывают. Парадокс: про него столько уже десятилетиями понаписано — книжек, статей, дискуссий, но что это такое – сегодня так и остаётся загадкой, причем: чем больше пишут – тем более загадочнее становится.

Не помогают ни книжки из серии «Для чайников», ни заветы CBOK, ни магические квадраты от Гартнера (BPM: BPA, BPMS, iBPMS и т.п.), в которых, как и в черных квадратах Малевича (а у него только черных было несколько «разных» вариантов) – каждый норовит увидеть что-то великое и таинственное, ведомое только ему.

В главе предлагается вариант классификации BPM-подобных сущностей. В информационной войне с «алхимией 21 века» продолжаем развенчивать популярные мифы о Business Process Management, Enterprise Architecture (ЕА) и иже с ними. Делаем очередной шаг на пути становления BPM как обычной (повседневной, повсеместной, тривиальной) инженерной дисциплины: process technology, «процесс-техника».

Читать дальше →

Типичные ошибки начинающего технического директора в ИТ — мнения экспертов

Время на прочтение8 мин
Количество просмотров38K

Изображение с сайта tech.co

От некоторых сотрудников ИТ-компаний до сих пор можно услышать такую реплику: «Я не совсем понимаю точное значение должности Технический директор». Как отметил в предельно простой форме один из пользователей «Тостера», «CTO — технический человек, который что-то понимает в бизнесе». Если рассматривать это понятие чуть шире, то можно сказать, что он балансирует на стыке между разработкой ИТ-продуктов с командой технических специалистов и принятием бизнес-решений совместно с менеджерами.

Соответственно, для специалистов, желающих занять позицию технического директора в ИТ, существует, как минимум два пути:

  1. стандартный — «Developer -> Senior -> Team lead -> CTO»;
  2. гуманитарный – «PM -> Senior PM -> CTO».

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

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

О том, какие ошибки и подводные камни ожидают новоиспеченных технических директоров в ИТ-сфере, мы попросили рассказать экспертов отрасли.
Читать дальше →

«Сапожник в своих сапогах»: как мы писали модуль управления финансовыми ресурсами для внутренней СЭД

Время на прочтение7 мин
Количество просмотров4K
image

Не секрет, что мы в Хоулмонт сами используем СЭД ТЕЗИС. Странно было бы, имея в руках современный и надежный инструмент для хранения и согласования документов, пользоваться чем-то еще. Неудивительно и то, что для любой достаточно крупной компании штатной функциональности СЭД порой не хватает. В этой статье мы расскажем, как создавался дополнительный модуль к нашей внутренней СЭД ТЕЗИС — модуль управления финансовыми ресурсами, или просто модуль финансовых заявок, как мы его зовем. А заодно воспользуемся случаем и немного покажем, как проводится проектное внедрение системы на примере отдельно взятой организации.
Читать дальше →

Вклад авторов