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

Глядя на то, как с этим обстоят дела в среднем по IT-отрасли, осмелюсь дать достаточно негативную оценку: на мой взгляд, собеседования полны субъективности и случайности, а среднее качество отбора получается весьма посредственным — работодатели жалуются на неадекватность запросов кандидатов, вакансии могут оставаться незакрытыми месяцами, а принятые в штат сотрудники часто не оправдывают ожиданий.

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

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

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

Привет, меня зовут Александр Волков, я проектирую интерфейсы в компании Docsvision. Цель этой статьи — помощь разработчикам сложных программных продуктов. Ключевое слово — сложных. Спроектировать сайт-визитку сегодня может даже пятиклассник прямо на своем смартфоне, и при желании можно скачать зип-архив с готовым шаблоном блога или корпоративного сайта. Однако если ваше приложение посложнее обычного интернет-магазина, то, вполне вероятно, строить структуру и определять принципы навигации вам придется самостоятельно, наступая на разбросанные повсюду грабли. Здесь может пригодиться наш опыт. Я опишу один из возможных способов проектирования интерфейсов, который успешно опробован в нашей компании. Это делается легко и просто (практически в полуавтоматическом режиме) при помощи программы FlyingLogic.

Чем грозит долгострой в разработке и с какими трудностями предстоит столкнуться на этом пути? Как бизнес-аналитик компании, которая 15 лет занимается разработкой и поддержкой одного продукта (СЭД), я решила поделиться своими мыслями и примерами из практики. Проблематика управления требованиями в любых программных продуктах с длительным периодом реализации – актуальный вопрос для аналитиков, руководителей проектов и владельцев продуктов. И, возможно, для непосредственных партнёров и заказчиков Docsvision, ожидающих выхода новых версий и заинтересованных в появлении новой функциональности.

Добрый день, меня зовут Сергей и я руководитель продуктового направления в компании «ДоксВижн». За время работы в сфере автоматизации электронного документооборота мне довелось участвовать в десятках проектов внедрения, причем в разных ролях (от инженера до руководителя проектного офиса), с разных сторон (заказчик, представитель компании-внедренца, вендор) и с разными системами (Docsvision и Directum). Своим проектным опытом я хочу поделиться с вами.

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

Здравствуйте, меня зовут Наталья, я инженер по тестированию компании Docsvision.
Иногда, когда я просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками, рука машинально тянется к лицу. В голове возникает только одна мысль:



«Что? Что я сейчас прочитала?»

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