Сайту viva64.com — основной площадке разработчиков анализатора кода PVS-Studio исполнилось 10 лет! Домен был зарегистрирован 09.11.2006 года, а последнее серьезное обновление дизайна было выполнено в декабре 2010 года. Пришло время что-то поменять.
Мы продолжаем расспрашивать специалистов о режиме труда и отдыха, профессиональных привычках, об инструментарии, который они используют, и многом другом.
Будет интересно выяснить, что их объединяет, в чем они противоречат другу другу. Возможно, их ответы помогут выявить какие-то общие закономерности, полезные советы, которые помогут многим из нас.
Сегодня наш гость — Дмитрий Столяров, технический директор Флант. Его лайфхаком хотели бы воспользоваться многие, но далеко не все могут себе это позволить. (далее…)
Мне не раз приходилось слышать: «Upwork — это же геморрой. Мне приходится тупо кликать мышкой, смотреть фильм на ноуте, чтобы побольше высидеть часов. Поэтому я ушел на XYZ…». Вот этот тезис, личные проблемы с продуктивностью, а также немалое количество self-help книг, побудили меня написать этот пост.
Вся моя IT-карьера, связана с Upwork (который был oDesk). Это немного-немало 10,000+ часов работы и 10+ лет проведенных в этой системе, с короткими перерывами. За это время я заработал 220k$+ и выполнил 50 проектов.
Но была одна серьезная проблема, баг в моей ментальной системе — это регулярное выгорание от работы, которое я не осознавал. Было плохо, нервозно, тревожно, но причину не удавалось найти. Она сидела где-то глубоко в подсознании, зарывшись поглубже еще в раннем детстве и не позволяла увидеть реальное положение вещей. Как наступило просветление и что делать во избежание выгорания — читайте под катом.
Встречаясь с огрехами и ошибками удобства очередной CRM/системы управления проектами — возникает мысль написать-таки свой велосипед, однако экономическая ситуация в нашей стране, да и отсутствие многих часов времени на контроль останавливает меня от столь разумного шага, поэтому — приходится выбирать из того, что есть.
А раз уж все равно выбирать — почему бы не написать об этом? (далее…)
Трудоголиков становится все больше, а предприниматели, программисты, дизайнеры и маркетологи часто объясняют свои переработки тем, что им просто нравится своя работа.
По результатам исследования, проведенного в Стэнфордском университете, программисты, которые проводят в офисе на 20 часов в неделю больше нормы (то есть 60 часов вместо стандартных 40), выполняют свою работу менее качественно. Таким работникам чаще нужен отдых, чтобы их производительность не страдала.
Мы в 1cloud рассматриваем самые разные темы, связанные с ИТ. Сегодня мы решили немного поговорить о культуре работы и отдыха, рассмотрели примеры отпускных поощрений некоторых ИТ-компаний и общую ситуацию с модой на трудоголизм.
Мы продолжаем расспрашивать специалистов о режиме труда и отдыха, профессиональных привычках, об инструментарии, который они используют, и многом другом.
Будет интересно выяснить, что их объединяет, в чем они противоречат другу другу. Возможно, их ответы помогут выявить какие-то общие закономерности, полезные советы, которые помогут многим из нас.
Сегодня наш гость — Петр Зайцев, генеральный директор, основатель Percona. Он считает себя не самым организованным руководителем. Более того, Петр, будучи человеком технического скалада, называет себя «нетипичным СЕО». (далее…)
Хотите ускорить рост, повысить конкурентоспособность, вырваться вперед? Тогда, возможно, пришло время переосмыслить свой подход к планированию продукта. Дженна Бэстоу из Invision делится в блоге компании опытом внедрения тематических дорожных карт в рабочий процесс и рассказывает о преимуществах, которые принесло команде это решение.
Тематические дорожные карты проекта — это не пошаговая методика; они не предполагают строгих правил и не привязывают вас к определенному продукту или программе. По сути, это просто гибкий подход к разработке стратегии.
Выглядит он так:
А звучит так:
«Что готовит будущее, мы не знаем. Поэтому вот список того, что мы хотим сделать, в общих чертах, а коррективы вносить будем по ходу дела».
(далее…)
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Наука, связанная с обработкой данных, продолжает волновать людей, однако реальные результаты нередко вызывают разочарование у заинтересованных бизнесменов. Как мы можем снизить риски и обеспечить соответствие результатов ожиданиям? Работа в качестве технического специалиста на стыке НИОКР и коммерческих операций дала мне представление о проблемах, которые стоят на этом пути. Я представляю свою личную точку зрения на наиболее распространённые виды провалов и неудач проектов, связанных с информатикой.
(далее…)
Методика освоенного объема (МОО) 1 2– технология обкатанная и, однозначно, эффективная. Однако, решившись ее применять, следует иметь в виду несколько явных и известных ограничений, которые сильно снижают коэффициент ее полезности её КПД.
Во-первых, применять МОО следует только после того, как прошла некоторая часть проекта (порядка 15%-20% 3. Эта фора необходима для того, чтобы накопилась достаточная статистика по проделанной уже работе, и показателям, входящим в методику, таким как SPI/CPI, можно было бы смело доверять.
Во-вторых, именно базовые показатели МОО не учитывают связанность проектов между собой и влияние форс-мажорных событий на результаты отслеживаемого проекта и будущих задач. Например, если ключевой разработчик внезапно заболел или неожиданно уехал по срочным делам – срываются сроки текущего проекта, а также сдвигаются сроки последующих работ, которые запланированы на него, но пока не мониторятся. В силу того, что плановые задачи находятся в категории «будущего», их показатели не измеряются. Тем не менее, случившийся сбой на них в перспективе тоже отразится.
Именно поэтому, применяя МОО на практике, следует учитывать данные риски и снимать ограничения, которые были обозначены выше. Рассмотрим этот принцип на примере некоей ИТ-компании, занимающейся реализацией проектов в интересах заказчика.
Понятно, что в одной короткой статье нельзя уместить весь спектр рисков, с которым сталкиваются в повседневной деятельности руководители проектов и производственных подразделений. Тем не менее, этот пример позволит узнать, как заранее разглядеть «грабли» заботливо разложенные реальностью, и обойти их, не сломав при этом производственные процессы.
