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

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

Ежедневная работа состоит в основном из рутинных дел, и программисты — не исключение. Но часто именно на таких делах и держатся все проекты. Поэтому руководство рабочими процессами в IT-компаниях или отделах должно включать контроль деятельности сотрудников и напоминание о важности этих дел.

Мы в 1cloud считаем, что программисты очень похожи на художников. Так же, как и в сфере искусства, IT-специалисты часто мыслят творчески. И хотя искусство нельзя загонять в какие бы то ни было рамки, правильная постановка задач, мотивация и контроль помогут удержать функционирование компании на плаву.

В качестве эпиграфа: "Выкиньте все из головы!" © D.Allen

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

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

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

Я работаю обычным аналитиком и, так получилось, что летом 2014 года, участвуя в одном e-commerce проекте, на коленке за 3 недели сделал управленческий учет в MS Excel. Давно планировал и наконец-то решил выложить на Хабр. Думаю, будет полезно малым предпринимателям, понимающим важность управления финансовыми потоками, но не желающим тратить значительное количество времени и средств на ведение управленческого учета. Не претендую на истину в последней инстанции и буду рад иным решениям, предложенным участниками сообщества.

Многие любят читать мотивирующие статьи типа «30 способов заставить себя работать». Да и писать многие любят. Но что многие не любят — так это писать о том, что советы, изложенные в этих статьях, у них не сработали. То есть советы-то разумные. И применить их часто пытаются. Но есть одна проблема — стоит начать их применять, как возникает огромное внутреннее сопротивление. Настолько огромное, что применить советы не получается. Так в чем же дело?

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

В преддверии Java-конференции Joker 2015, которая начнется уже завтра, я публикую большое интервью с Алексеем Шипилёвым, инженером команды Java Performance Team из Oracle, одним из самых крутых и известных во всем мире специалистов по производительности. Ну и конечно, прекрасным спикером.

С Алексеем мы подробно поговорили:

• про грядущие изменения в классе String;
• про то, кто же на самом деле разрабатывает OpenSource;
• про системных разработчиков и их карьеру;
• про обмен технологиями, «научную» и «продуктовую» разработку;
• про сложность низкоуровневых задач;
• про развитие Java-сообщества и бенчмарк-войны;
• про mutable vs immutable;
• про Unsafe;
• про JMH, бенчмарки и узкую специализацию.

Вот видео нашего разговора. Больше часа длиной, можно слушать в дороге.



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

Однажды человек ехал по автостраде на своей машине… Повсюду туман. Как говорится, ехал «на интуиции»… Ладно туман, так еще и машина без фар, спидометра, только колеса, руль и кузов… Бах! Стена, авария, ремонт, разбитые судьбы, расходы.

История фантастическая, не так ли? Тогда почему 90% компаний двигаются абсолютно также, вслепую? Рассчитывая только на интуицию и без понимания того, что происходит в компании на самом деле?



Многие founder'ы, предприниматели и стартаперы слышали про суть и пользу «оцифровки» бизнеса, видения ключевых показателей. Многие слышали и знают о RoiStat, SmallData, BigData и так далее.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Мне всегда нравилась идея — работай меньше, делай больше. Но в моей жизни было время, когда я действовал по-другому. Несколько видов деятельности так сильно интересовали меня, что я никак не мог определиться на чем сосредоточиться. Логичнее было бы использовать правило 20% и отсечь все остальное, но я этого делать не стал и кое-что понял.

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

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

Если вы не готовы тратить на английский хотя бы 2 часа в день, то дальше можно не читать.

В 2009 году Винсенту ДеВита, бывшему директору Национального института онкологии США и профессору медицины в Онкологическом центре на факультете медицины Йельского университета, поставили диагноз: рак простаты. Обычно при этом заболевании назначают гормональную терапию, но де-Вита повезло — его коллеги провели ему операцию, которая выходит за рамки стандартного лечения, и это спасло ему жизнь.

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

По мнению ДеВита, фраза «Нам не удаётся победить рак» говорит не о том, что человечеству не хватает для этого знаний, а о том, что бюрократия не позволяет им воспользоваться достижениями науки.

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

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

Между тем, сколько-нибудь заслуживающих доверия данных о влиянии порнографии на общественное и личное здоровье в этих обсуждениях нет; более того, мои попытки по-быстрому найти какие-то вменяемые данные в интернете не увенчались успехом. В поисках ответов на вопросы мне пришлось погрузиться довольно глубоко в научные исследования, и кое-что я в итоге нашёл. Краткий синопсис современных научных взглядов на порнографию и её влияние на человека будет дан под катом после небольшого FAQ'а.

Вопрос: картинки будут?
Ответ: будут.

Вопрос: какое отношение этот топик имеет к Хабру?
Ответ: он интересен читателям Хабра.

Вопрос: нет, всё-таки, какое отношение имеет топик к тематике Хабра?
Ответ: никакого; просто я считаю, что Хабр — это, прежде всего, определённая аудитория, а не тематика.

Вопрос: почему в блог «Интернет»?
Ответ: потому что Internet is for porn.

Busfor — «Uber для автобусов», как его охотно называют англоязычные издания, или билетный агрегатор международных и междугородных автобусных пассажирских рейсов. На прошлой неделе проект привлёк $20 миллионов от новых инвесторов — фондов Baring Vostok и Elbrus Capital, в то время как текущий акционер — InVenture Partners — увеличил вложения в компанию. Общая сумма привлечённых средств к текущему моменту составляет $25 миллионов.

Как отмечают западные аналитики, вполне возможно что мы имеем дело с новым потенциальным «единорогом», так как рост Busfor вполне можно назвать впечатляющим. К 2019 году компания надеется занять 20% рынка билетов, одновременно ускоряя рост на существующих (компания оперирует в России, странах СНГ, восточной Европе и Таиланде) и новых рынках, таких как Азия.

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

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

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

Изначально CRM-системы создавались именно для продаж. Группа программного обеспечения, призванная облегчить труд продажников, получила название sales force automation (SFA) — автоматизация торгового штата. Собственно, именно от этого факта и получила своё название одна из самых старых и самых известных мировых систем — Salesforce. Но менеджмент не стоял на месте — в современных продажах клиент стал во главе угла, CRM-системы (системы управления взаимоотношениями с клиентами) стали популярнее SFA (но не равны им!). На этом месте обычно долго рассказывают о лояльности, предиктивном маркетинге и прочих пиар-штучках, но посыл гораздо проще. Что бы мы ни создавали, будь то корпоративный софт, игра, приложение или дата-центр, это нужно продать, быстро обойдя конкурентов. И у нас, программистов, это получается не очень. Точнее, не получается вообще.

Может, задачка и простая, но зацепило :)

У вас есть зеленые и красные помидоры. Все перемешаны, и находятся в одном большом ведре. Как за минимально короткое время рассортировать их (красные — отдельно, зеленые — отдельно), не прикасаясь к ним руками?

Пожалуй, редкий зритель не смотрел фильм День сурка. Помните, когда Фил рассказывает мужику, с которым сидит за выпивкой в баре, о своей проблеме, тот отвечает: «это история моей жизни».

Немало людей сталкиваются с проблемой распределения времени между задачами, расстановкой приоритетов.

Посмотрим на примере одного рабочего дня, как все меняет пара движений.

До.

С утра прихожу, открываю IDE, загружаю проект. По аське приходит — привет, не посмотришь? Переключаюсь на задачу, смотрю — кажется, пустяк. Сажусь делать — выплывают дополнительные подробности, неожиданные моменты, углубляюсь в процесс. Гуглю. Открываю Хабр, думаю глянуть пару статей. Зависаю на Хабре… слышу голос: «Идешь обедать?». Опа — на часах уже два.

«Чтобы стать экспертом в практической или научной области, нужны огромный труд и долгое время. Если человек добросовестно трудится каждый час рабочего дня, когда-нибудь он проснется одним из самых компетенткых специалистов своего поколения.»
Ульям Джеймс

Мы с вами много говорим о том, как нужно строить архитектуру ПО, как следует выбирать имена для переменных, каким образом лучше документировать код и почему, и т.д.

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

В этой статье попытаемся ответить на вопрос, какими же качествами должен обладать человек для того, чтобы писать совершенный код.