Рубрика «управление проектами» - 351

Как программисты, мы гордимся нашей работой. Мы показываем эту гордость, выполняя наши задачи лучшим образом. Мы относимся к ним со всей дотошностью, вплоть да названий переменных и методов. Мы всегда выбираем нужные классы для конкретной задачи, не смотря на то, что пользователю все равно, использовали ли мы List<KeyValuePair<Guid, string>> или Dictionary<Guid, string>. Мы нервно стараемся довести все до идеального состояния. Многие даже могут подумать, что у нас ОКР.

Но что происходит, когда разработчик слишком гордится тем, что он или она написали?

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

95% своей сознательной жизни я связан с ИТ, начав как переводчик, достаточно быстро перешел в ИТ, развитие проектов, в общем кто плавал, тот поймет.

Основная проблема, с которой я столкнулся, во время своего путешествия, это конечно люди. Не плохие люди и не хорошие, а просто люди-сотрудники.

Так вот, в любой нормальной ИТ компании, которая занимается программерством, 90% это программисты процентов 7% технари, остальное административный отдел. Самые простые люди в компании это конечно администраторы, в прямом смысле этого слова, те люди кто делают чай, кофе, чистоту, учет и безопасность. И так часто происходит что именно эти люди самые бесправные, вы знаете что их легко заменить, их никто не замечает и тд и тп.
Читать полностью »

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

Стратегия продукта подразумевает ответ — «Нет!»

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

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

Вот глоссарий терминов, а вот каталог IT-услуг. Эти документы можно свободно скачивать и использовать. Особенно рекомендую это руководителям IT-подразделений.

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

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

Что это действительно значит быть «младшим программистом»
Вечер пятницы, я получил имэйл от моего приятеля, который только что закончил колледж (Рочестерский Технологический Институт) и работает в весьма многообещающем стартапе, занимающемся программированием C++ систем и обучением искуственных интелектов. Ниже небольшой фрагмент его письма.

Чувак, одна вещь на работе не дает мне покоя – хотя мои коллеги по большей части приятные люди, я чувствую, как будто мою работу совершенно не ценят. Я работаю с шестью инженерами (вместе мы составляем команду из семи инженеров). Из шести, один — Platform Architect (Архитектор платформ), двое – Старших Инженеров-Прикладников, еще один – Software Architect (Программный Архитектор), остальные два отвечают за Обеспечение Качества. Если честно, и я не хочу, чтобы это прозвучало надменно, но за исключением одного Старшего Инженера-Прикладника, я понял, что знаю намного больше чем все эти «старшие» парни. Не пойми меня неправильно… они занимаются этим уже много лет, работают над важными системами и все такое, но я более образован чем они. Чаще всего, из-за того, что я Младший Системный Инженер, мои идеи просто отметаются и моя напряженная работа совершенно не ценится… откровенно говоря, это меня ужасно бесит. Иногда я подумываю о том, чтобы вернуться к фрилансу (особенно учитывая, что я уже закончил колледж).Читать полностью »

На каких языках говорят наши пользователиТо, что в KolibriOS есть не-русскоговорящие разработчики (хоть их и очень мало), некоторым из вас уже известно по моему предыдущему посту. Однако разработчикам самим, в свою очередь, интересно знать, есть ли у нас не-русскоговорящие юзеры.

До того, как мы задались этим вопросом, KolibriOS выпускалась на 2 языках: русском и английском. Соответственно, каждая новая фича и каждая правка программы/ядра требовали от программиста, их делавшего, добавления/исправления всех сообщений, кнопок и лейблов на обоих языках.1 Может быть, целесообразно перестать выпускать английскую сборку, и сконцентрировать все свои усилия на русской?
Читать полностью »

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

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

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

image
На форуме, посвящённом оказанию ИТ-услуг, один аутсорсер задал вопрос, какую концепцию рекламы лучше выбрать для своего бизнеса – публикации в тематических изданиях, распространение листовок, SEO, контекстную рекламу или телемаркетинг. Ответы были банальные: главное – рекомендации, реклама ничего не даёт, а если и даёт, то только поисковая оптимизация (SEO).

В этом обсуждении меня заинтересовали два момента (помимо утверждения, что реклама ничего не даёт, но сейчас не об этом). Первое: ни топикстартер, ни участники обсуждения даже не упомянули такую маркетинговую коммуникацию, как direct mail. Наверное, потому что не видят разницы между direct mail и спамом. Второе: моя попытка донести до участников обсуждения, что концепция рекламы – это не столько способ донесения информации до целевой аудитории, сколько содержание рекламного предложения, окончилась полным провалом.

Поразмыслив, я решил, что эти вопросы заслуживают не разрозненных комментариев, а отдельной статьи. Я постараюсь не углубляться в дебри теоретизирования, а показать на конкретных примерах, как можно искать клиентов в области предоставления ИТ-услуг, используя direct mail и оригинальное по содержанию рекламное предложение.
Читать полностью »

Существует много модных современных концепций: Agile, Lean Startup, Customer Development, Worse is Better, TDD, SaaS. Все они хороши. Вникание, а тем более использование, сильно расширяет горизонты. Но надо понимать, что это всё довольно общие вещи. Нужно не забывать использовать голову и чётко осознавать применимость в собственном проекте.

Фанатичное следование методологии напоминает восторг от осознания какой-то возможности в языке программирования. Я сам поддавался такому не раз: «Круто, в Python есть метаклассы — срочно используем в проекте» — несмотря на то, что того же самого можно было добиться обычными атрибутами класса. «Вау, макросы Lisp — это супер, накодим их побольше» — хотя можно было обойтись функциями высшего порядка. Сначала делаешь так, а со временем свыкаешься и уже не суёшь эту мощную возможность куда попало, а используешь, только если она действительно нужна.

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

Где тот момент, когда они устаревают? Где те условия, в которых они работают, и в которых уже нет? Может быть, новый тренд уже стал устойчивым стереотипом и необходимо движение дальше? Эти вопросы нужно всегда задавать себе и пользоваться/не пользоваться концепцией не потому что она прогрессивна/устарела, а потому что она подходит/не подходит лично вам в конкретном деле.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js