Наша команда недавно перебралась в новый офис и так получилось, что в нем не оказалось места для доски управления задачами. Решение пришло почти мгновенно — использовать вместо нее google-календарь.
Им удобно пользоваться, есть совместный доступ, собственно, почему нет? (далее…)
В среднем, более трети всех утечек информации случаются по вине сотрудников. Понятно, что гибкость и универсальность людей работают в обе стороны и позволяют нам не только воспринимать и обрабатывать любую информацию, но и терять её большим количеством способов. Странно то, что несмотря на простоту и очевидность правил, которые препятствуют утечкам, их постоянно нарушают, что приводит к курьёзным и не очень случаям.
Незамысловатое правило: следите за доверенными вам вещами. Согласитесь, ведь глупо оставить чемоданчик с секретными документами на видном месте, а самому уйти обедать. Почему так происходит? Секретные документы забывают где угодно: в закусочных, поездах, трамваях, такси, отелях и телестудиях. И ведь делают это не какие-то простые люди, а премьер-министры и сотрудники спецслужб. Даже Штирлиц может оставить секретные документы впопыхах (на следующий день в Попыхи нагрянуло Гестапо).
К тому же правилу можно отнести мирно лежащие на столе мобильники и незаблокированные рабочие компьютеры, просто о таких вещах журналистам не интересно писать. Большинство сотрудников быстро привыкают к рабочей обстановке и чувствуют себя в офисе как дома. Часто это приводит к тому, что незнакомый народ с улицы: курьеры, клиенты и кандидаты на вакансию — автоматически становятся гостями, которых нужно радушно принять. Чайку изволите? Постойте тут пока рядом с моей табличкой с клиентами, а я вам схожу чаю налью. Действительно, что может быть плохого?
(далее…)
Действующие лица:
X – крупная известная компания, в которой открыта вакансия аналитика (условно)
A – сотрудник компании X, который проводил собеседования
B – представитель отдела HR компании X
С – кандидат на вакансию аналитика.
(далее…)
Изобретения делают люди. Деньги на изобретениях делают фирмы. Как фирме избежать проблем с автором изобретения и другими заинтересованными лицами? Читайте разъяснения патентного эксперта.
(далее…)
Вот уже почти три месяца я уволился из офиса и работаю на «вольных хлебах». «Халтуры» попадались и до этого, но я не брал более одного проекта и делал лишь то, что входило в мою широкую, но не безграничную область компетенции.
Я занимаюсь «программированием под ключ» и считаю себя μISV. Специализируюсь на проектах, требующих смежной компетенции, обычно я работаю с заказчиками долго — по нескольку лет. Я за то, чтобы исполнитель и заказчик работали вместе и помогали друг-другу найти оптимальное видение проекта. Мой процесс разработки выглядит так: (далее…)
Рассмотрим следующую ситуацию: вы — проджект-менеджер, и на вашем проекте возникла проблема. О том, как поэтапно добраться до источника проблемы и ликвидировать ее, я подробно расскажу в сегодняшней статье.
У меня все работает!
Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают. Однако что происходит, если на проекте нет менеджера? Представим ситуацию: в саппорт приходит гневное письмо: «Я нажал на кнопку, а там 500-я ошибка!». Причем письмо приходит не одно, то есть проблема массовая.
(далее…)
Главная задача менеджера удержать проект в пределах «железного» треугольника. Поэтому ему просто необходимо анализировать и прогнозировать отклонения проекта по срокам и затратам. PMBOK (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, Project Management Institute, Inc., 2013) рекомендует использовать для такого анализа метод освоенного объема (Earned Value Technique).
Бытует мнение, что этот метод не применим в управлении программными проектами. Это действительно так, если мы используем «водопадную» модель процесса разработки, в которой на верхнем уровне декомпозиции находятся производственные процессы: анализ, проектирование, кодирование, тестирование, документирование. Даже закодировав 90% требований, мы, к сожалению, ничего не можем сказать о готовности нашего продукта. Может оказаться так, что при проектировании была допущена ошибка и большую часть кода придется переписывать.
Однако, если иерархическая структура работ нашего проекта, ориентирована на итеративную и инкрементальную разработку, то на верхнем уровне декомпозиции находятся компоненты проектного продукта, а на следующем — их функционал. В ‘том случае метод освоенного объема вполне себе применим. Поскольку, если в проекте реализованы, протестированы и документированы 50 % функциональных требований (а лучше, если еще и представлены заказчику), то есть все основания полагать, что осталась приблизительно половина проектных работ.
Суть метода оценки проекта по освоенному объему заключается в следующем.
(далее…)
Этот текст был задуман как попытка структурировать основные принципы успешной технической поддержки и общения в целом. Под «успешной» в данном контексте подразумевается положительная реакция непосредственно клиента на качество сервиса, т.е. его конкретное субъективное мнение по итогам обращения в техподдержку.
Немного об авторе: никакого психологического образования не получал, курсов общения с клиентами не проходил, так что все выводы основываются исключительно на личном опыте. Я начал работать в технической поддержке более 8 лет назад, в компании Acronis, тогда еще совсем небольшой, а штат техподдержки не превышал 10-15 человек. Сегодня в техподдержке участвует более 250 человек, поддерживая клиентов на девяти языках мира. Со временем я прошел все этапы — от работы в небольшом коллективе с практически нулевым уровнем личной ответственности до контроля и взаимодействия в большой инфраструктуре, включающей автоматический сбор статистики по каждому сотруднику для замеров его личного KPI (key performance indicators).
Благодаря длительному общению с пользователями (как правило, англоговорящими) сами собой выкристаллизовались манеры успешного общения — что именно нужно делать и как себя вести, чтобы клиент остался доволен. Эти правила одинаково применимы не только к технической поддержке программных продуктов, но и к общению с клиентами в любой другой отрасли, так что, надеюсь, сей опус будет полезен не только узким специалистам, но и пригодится в повседневном общении. Лично мне это сильно помогло.
Привет, Хабр!
Когда в разговорах с айтишниками заходит речь про учет трудо-часов, холивор зажигается моментально. И не важно, с кем про это говорить: тема задевает и рядовых разработчиков, и тимлидов, и топ-менеджеров. Предлагаем на обсуждение наше видение темы с учетом часов — может, мы продвинемся немного в поисках истины в процессе обсуждения.
-Gartner-—-pri-vnedrenii-novoi-sistemy-na-predpriyatii.png "Цикл зрелости технологии (Hype cycle) Gartner — при внедрении новой системы на предприятии")
В 1995 году исследовательская компания Gartner предложила hype cycle — кривую зрелости технологии, графически представляющую стадии, через которые проходит технологическое новшество в ходе своего становления.
Данный феномен наблюдается при появлении любой новой техники, будь то появление планшетов на рынке или внедрение новой CRM системы на предприятии.
Про то как эта кривая работает в части электроники, написано много статей.
А вот как она работает в ходе внедрение новой системы в организации?
(далее…)