О том, что надо делать с опозданиями

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

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

Если продолжить эту аналогию с заводом, то мы увидим, что для поддержания такого процесса нужна определенная жесткость. Приходить на работу надо ровно в срок, чтобы занять свое место у конвеера точно со всеми остальными по расписанию. Производственная культура может поддерживаться строго, используя штрафы к плохим рабочим вплоть до увольнения. Еще Форд писал, что они в 3 дня могли обучить нового рабочего и поставить за рабочее место на конвеер. Человека найти просто, обучить недолго и требования к нему средние.

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

Я почему говорю о штрафах. Приходилось бывать и слышать о совещаниях, где обсуждаются вопросы опозданий сотрудников на работу. Когда общими усилиями менеджеры решают, что приходить надо с 9:00 до 9:30, то тут же встает другой вопрос: “Что делать с теми кто опаздывает?”

– Надо штрафовать! — говорят одни.

– Вплоть до увольнения. — вторят другие.

А если взять конкретный пример? Получится так, что ведущий дизайнер, талантливый как Сальвадор Дали, опаздывает хуже всех. И что с ним делать? Штрафовать вплоть до увольнения? Ха. Кто же даст это сделать!

Вот и получается тупик. А все потому что “в свое время”, это когда надо для всех, а не когда кому-то так хочется. Человек должен успевать к процессу, а не к завтраку.

Источник: http://yuri.shilyaev.com/

Проблема опоздания в т.н. “наших конторах” вещь постоянная и часто трудно контролируемая. Я полностью согласен с Юрием, который говорит: “Программиста порой приходится искать несколько месяцев, требования к сотрудникам бывают довольно высокие, как следствие, применить штрафные санкции (такие как увольнение) бывает весьма сложно или невозможно в принципе. Надо подходить творчески.”

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

Если у кого-то есть методы мотивации дизайнеров на работу и на приходы на работу, напишите будет очень интересно.

JIRA – багтрекер для широкого круга задач

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

Atlassian JIRA (http://www.atlassian.com/software/jira/) – система чуть более широкая, чем только багтрекер, это Issue Tracking system – то есть система трекинга сообщений как таковых.

Что умеет создавать:
Сообщения с определённым (управляемым администратором) набором полей, в том числе, такими распространёнными как: тип (ошибка, предложение, задание – список расширяем) ; responsibility (Assignie) – ответственный, получатель сообщения; приоритет; воспроизводимость; компоненты (очень удобная штука, если проект состоит из нескольких модулей или подсистем); версия в которой создаётся сообщение (affected version); версия в которой сообщение будет снова иметь силу (fixed version) – словом, стандартный набор полей для багтрекера. Стандартный, но при этом расширяемый для каждого проекта. То есть система ведёт несколько проектов с непересекающейся версионностью и своим уникальным набором полей.

Как происходит трекинг:
Создаваясь, сообщение обязательно имеет Assignie – ответственного, адресата (если такового не указать система в зависимости от настроек конкретного проекта либо автоматом «направит» сообщение, то есть адресует его, лидеру проекта (указывается при создании проекта), либо укажет необходимость выбрать адресата, если проект настроен так, чтобы сообщения не могли быть безадресными. «Получатель» может перенаправить его далее или вернуть писавшему ("петля разработчик-тестировщик").

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

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

Аттачи:
Небольшое приятное дополнение к опции «Attach Files», особо нужное если работаешь под «голой» операционкой, на которой нет средств редактирования и сохранения изображений (или как в случае с маком – такие средства есть, но пользоваться ими вин-пользователю неудобно жутко, да кроме того потом нужно ещё суметь достучаться по сети до сетевого ресурса, с которого потом этот файл можно будет приаатачить к сообщению об ошибке) – опция "Attach screenshot". Аттачить скриншоты, то есть буквально то, что на данный момент снято в буфер обмена, можно прямо в JIRA, с помощью небольшого java апплета, который отлично работает и под вин-системами и под маком. Согласитесь, удобно.

Аттачить можно не только картинки, но и доугие форматы файлов, однако если аттачить gif, jpg или bmp JIRA сама при просмотре сообщения сделать для них превьюшки. Это просто и удобно, ведь никто не гарантирует, что разработчик просматривая это сообщение будет иметь под что-то, кроме браузера.

Пользователи:
Аккаунты пользователей управляются как администратором, так и самим пользователем. Пользователи могут быть объединены в группы – то есть совершенно привычная структура. При чём как отдельному пользователю так и группе можно запретить/разрешить одно вполне конкретное действие (к примеру такая экзотика, как запрет на удаление аттачей и создание комментариев для менеджеров из других проектов).

Безопасность:
Умеет создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект.

Оповещение:
Как узнают пользователи о том, что их сообщение было отредактировано, или о том, что им адресовано новое сообщение. По аналогии со «схемами безопасности» каждому проекту может быть создана «схема оповещения», в которой указывается на какое событие как должна реагировать система оповещения, которая рассылает почтовые сообщения. К примеру хочется получать сообщения не только если сообщение направлено непосредственно вам, хочется отслеживать своё сообщение. Или к примеру мне, как ведущему тестировщику, нужно видеть все создаваемые моей командой сообщения об ошибках – при этом видеть не просматривая все проекты, которые в данный момент активны, отыскивая созданные сообщения, а прямо из почтового клиента перейти к сообщению, чтобы внести нужные изменения. Схемы оповещений могут быть расширены к примеру в следующем ключе: обо всех сообщениях, которые приходят на определённый проект, должны быть поставлены в известность ведущий разработчик этого проекта и ведущий тестировщик. Для схем оповещений JIRA это реализуется без «танцев с бубном» и глубокого администрирования почтовой системы организации.

Чем JIRA подходит нам:
У нас много проектов и команда тестирования работает одновременно с несколькими проектами и командами разработки. Кроме этого, мы работаем под несколькими типами операционных систем, в том числе и такой недружелюбной для тестирования как MAC OS. Особые правила обработки сообщений и оповещений для различных проектов, свободно уживаются в JIRA, не конфликтуя и давая возможность гибко ими управлять. Об удобстве работы с аттачами из под различных тестовых окружений, я писал выше. Различаются и требования к схемам оповещения и политики доступа и безопасности – со всем этим JIRA справляется легко, и как-то естественно. Чувствуется, что людям, которые принимали участие в её проектировании приходилось работать в нашем режиме.

Выводы:
Нужно пробовать, особенно если вы сейчас в процессе поиска и выбора багтрекера. Если же нет – просто познакомьтесь с этой системой поближе, возможно откатайте на ней «пилотный» проект. Вам понравится эта гибкость и надёжность.

Источник: http://notes.software-testing.ru/jira.htm

Проведение совещаний от Google

Вице-президент компании Марисса Майер проводит, в среднем, по 70 совещаний в неделю. Это и неудивительно, ведь она играет роль главного посредника между многочисленными группами разработчиков Google и руководством компании. Сергей Брин и Ларри Пейдж встречаются с Мариссой каждый день.

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

1. Четкий план. Расписание совещания должно быть согласовано за некоторое время до его начала. Расписание — это некий договор между участниками совещания о том, что именно они собираются обсудить и каким образом это сделать за минимальное время. План, хотя и допускает изменения, должен быть четким.

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

3. Микро-совещания. В рамках длительных заседаний можно организовать ряд краткосрочных сессий по 5-10 минут на конкретные темы. Подобная «модульная» структура совещания позволяет легко изменить план мероприятия, если возникнет такая необходимость. Дело в том, что в календаре Мариссы Майер минимальные отрезки времени имеют продолжительность в 30 минут. В такой график трудно вклиниться. Единственный выход — 10-минутные блоки.

4. Индивидуальный прием. Каждый день после 16:00 Марисса Майер в течение 90 минут принимает к себе посетителей из числа сотрудников. Это небольшие встречи тет-а-тет, где можно решить текущие вопросы без предварительного расписания. Сотрудники приходят к вице-президенту, чтобы согласовать дизайн программы или, например, поделиться собственными интересными разработками. Именно на приеме у Мариссы были впервые показаны и одобрены такие проекты, как Google News, Orku tи Google Desktop. За полтора часа Марисса Майер успевает провести до пятнадцати встреч.

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

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

Кстати говоря, многие из этих правил используются не только в компании Google. Например, на недавней конференции Yahoo! Open Hack Day более полусотни хакеров выступили с небольшими демонстрациями своих разработок, при этом каждый имел по 90 секунд времени, а таймер отсчитывал время на стене. Такая система действительно очень эффективна.

Источник: http://www.habrahabr.ru/

Десять уязвимостей Web 2.0

Изменение технологической среды, обусловившее развитие Web 2.0, вызывают опасения о безопасности соответствующих веб-приложений - даже при должном уровне безопасности на сервере, системы оказываются незащищенными со стороны клиентских интерфейсов и веб-браузеров. Портал Help Net Security опубликовал список из десяти наиболее опасных вариантов атак систем Web 2.0.

Cross-site scripting атаки в AJAX: при этой атаке запускается скрипт с уязвимостями, через который затем осуществляется атака - все, что нужно хакеру - убедить пользователя открыть из браузера ссылку вредоносной страницы. Эта схема срабатывает и на традиционных приложениях, а AJAX расширил ее горизонты.

XML-заражение: атаке может быть подвергнута внешняя ссылка на XML-объект, что может привести к произвольному запуску файла или TCP-соединения, которое будет использовано взломщиком.

Выполнение зараженного AJAX кода: пользователь часто не в состоянии определить, совершает ли браузер AJAX-вызовы с использованием запросов XML/HTTP. При совершении AJAX-запроса к сайту, браузер каждый раз заново авторизуется с помщью cookies, создавая опасность для внешнего проникновения.

RSS/Atom - проникновение: одна из новых схем атаки на Web 2.0. RSS-потоки, попадающие в браузеры через веб-приложения, могут содержать Java-скрипт с ошибками, запус которого приводит к установке программ или краже cookies.

Web Service routing issues: недостаточная безопасность одного из промежуточных узлов может сделать доступным SOAP-сообщение в момент его пути из одной точки в другую.

Манипуляция параметрами SOAP: Различные манипуляции взломщика с одним из узлов SOAP-сообщений, такие как внедрение SQK, LDAP, XPATH, позволяют ему выбрать лучший вариант атаки. Некорректная или недостаточная проверка системой кода на входе создает возможность для атаки на приложения.

Внедрение XPATH в SOAP-сообщение: Часто большие XML-файлы содержат добавленные конечным пользователем секции когда, формирующие отрывки XPATH, за счет которых уязвимым становится весь документ. Если внедренный код запускается успешно, взлом может спровоцировать потерю данных. Единственные способ блокировать этот способ проникновения - проверять XPATH запросы, прежде чем передавать в ответ на них ценную информацию.

RIA thick client binary manipulation: У RIA (Rich Internet Applications), использующих возможности Flash, ActiveX Controls, как основные интерфейсы для веб-приложений, существуют такие проблемы безопасности, как управление текущими сессиями, совместные сессии. Кроме того, когда компонент полностью загружен в указанное пользователем место, взломщик может перепрограммировать бинарный файл и декомпилировать код.

Источник: http://webplanet.ru/

Кнопка рейтинга от "Яндекса"

Сразу же после выхода Яндекс.Блогов 2.0 с рейтингом российской блогосферы и аскетичным поиском пользователи предложили разработчикам сделать "выносную" кнопку с позицией блога в рейтинге, как у Блогуса или Toodoo. Обновление не заставило себя ждать и уже через несколько дней была выпущена реализация.

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

Источник: http://webplanet.ru/

Управление в стиле фанк

Я решил изменить название популярной книги "Бизнес в стиле фанк. Капитал пляшет под дудку таланта" авторов Кейл Нордстрема и Йонас Риддерстрэйла (кому интересно на Озоне можно купить эту книгу. В данный момент я дочитываю её и решил выкладывать блоги некоторые выдержки, которые мне наиболее понравились. Вот первая из них.

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

Босс мертв. Мы больше не верим в руководителей, которые всегда правы и притворяются, что знают больше, чем мы. Управление посредством цифр осталось далеко в прошлом. Руководство, построенное на страхе, больше не работает. Если управление - это, прежде всего, люди, то искусство управления должно превратиться в искусство человекоуправления.

Служба мертва. Мы больше не верим в кусочек бумажки, на котором написано "Должностная инструкция". Новая реальность требует гораздо большей гибкости. На протяжении почти всего XX века большинство менеджеров имели только одну работу и только одну карьеру. Теперь мы можем смело говорить о двух карьерах и работе на семерых работодателей в течение жизни. Времена верных и преданных компании служащих давно прошли. Скоро в центре внимания будет стиль жизни, а не карьера, и работа будет представляться вереницей проектов и великих начинаний.

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

Бизнес на доверии

Деньги могут дать человеку многое, но не всё. Жажда материальной наживы захлестывает всех повсеместно. Новый бизнес предлагают всему миру американцы. Суть его заключается в том, что некие компании организуют торговые площадки, где рекламодатели размещают свои предложения по подкупу блоггеров. Задача последних состоит в том, чтобы публиковать положительные отзывы о том или ином продукте. Блоггер затем получает вознаграждение за свою работу.

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

Пишем правильно

На днях наткнулся на сайт проверки орфографии. Все закричат, да что в этом такого. На самом деле ничего просто сайт не наш, а "забугорный" http://orangoo.com/spell/
и он тем не менее прекрасно проверяет русскую орфографию.




Хотя конечно у него нет проверки web-страницы как у аналогичного инструмента от ArtLebedev

"Забугорный" Web 2.0

Наиболее полный каталог проектов web 2.0. Полностью каталогизирован. Выполнен на flash. Советую всем посмотреть :)