Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 10849 сообщений
Cообщения с меткой

разработка - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] Вид и перспектива в дизайне уровней. Часть первая

Пятница, 22 Июля 2016 г. 12:17 (ссылка)

Нам, как дизайнерам уровней, часто приходится снабжать игроков большими объемами информации. Это необходимо по многим причинам. Иногда нам просто хочется блеснуть красивым гейм-артом, а иногда – направить игрока к выполнению цели, проработать историю или сюжет игры, создать или сбавить напряжение. Но прежде чем делать всё это, необходимо понять, как направлять внимание игроков туда, куда нам нужно. Подробнее об этом — в нашем переводе статьи Майка Стаута.









Планета Гаспар из игры Ratchet & Clank



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



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



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



Что такое вид и перспектива?



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



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

Перспектива – это вид, который открывается через узкий коридор деревьев, зданий и т.д.



Удачное построение вида и перспективы требует вдумчивого расположения ориентиров и акцентов игры, а также искусной расстановки камер. К примеру, в начале игры (или в любой момент после загрузки) дизайнер может разместить ориентиры и акценты в самом первом кадре, до того как игрок получит возможность управления.



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

Вид и перспектива – очень мощные инструменты, особенно если использовать их в сочетании с другими упомянутыми выше средствами привлечения внимания (вроде видеозаставок).





Вид на Тадж-Махал, открывающийся через узкий коридор (Diego Delso, Wikimedia Commons, License CC-BY-SA 3.0)



Зачем использовать вид?



1. Чтобы продемонстрировать крутой гейм-арт



Самое очевидное преимущество использования вида или перспективы – показать игрокам красивый гейм-арт: к примеру, как на этом скриншоте из Middle-earth: Shadows of Mordor.





Контрольный пункт в игре Middle-earth: Shadows of Mordor



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



2. Чтобы подчеркнуть изюминку игры



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





Открывающийся вид на первую планету в игре Super Mario Galaxy



Начальный открывающийся вид первой планеты в игре Super Mario Galaxy обращает внимание на её особую физику – изюминку игры. Камера расположена таким образом, чтобы округлый горизонт планеты и объекты, которые на нём появляются, акцентировали на себе внимание.



3. Чтобы направлять игрока



Этот скриншот из игры Elder Scrolls: Oblivion был сделан сразу по окончании обучения в подземелье. После выхода наружу игроку открывается этот вид, причем камера располагается именно под таким углом. Прием довольно часто используется в играх серии Elder Scrolls. Он позволяет дизайнерам точно знать, куда будет направлен взгляд игрока, когда он войдет в очередную дверь.





Вид при выходе из подземелья в игре Elder Scrolls: Oblivion



Обратите внимание на то, как линия причала направляет ваше внимание к руинам. Руины не имеют никакого особенного значения в игре – просто разработчики Oblivion хотят научить игрока жить в открытом мире. Они побуждают его отправиться исследовать этот мир, не принуждая его делать что-либо конкретно. И такой вид прекрасно помогает донести эту идею.



4. Чтобы исследовать сюжет или историю игры





Глядя на этот скриншот из игры Super Mario Galaxy, можно сделать два любопытных наблюдения:



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



1. Перспектива, создаваемая двумя холмами, направляет внимание игрока вдоль тропинки, которая ведет на следующий уровень.

2. Игрок видит небо в образовавшейся перспективе, а падающие звезды становятся ключом к пониманию всего сюжета игры.



В начале Half-Life 2 игроку нужно как-то рассказать о том, что произошло с момента последней игры. Скриншот сделан на раннем этапе игры, когда игроку еще почти ничего не известно.







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



Совет: Управление камерой



Дизайнеру не нужно полностью контролировать камеру, чтобы продемонстрировать игроку хорошие виды. К примеру, вид на приведенном выше скриншоте из Half-Life 2 не навязывается: персонаж просто выходит из поезда и поворачивает налево. Но поскольку ему и так нужно идти по этому узкому коридору между поездами, он гарантировано увидит такую картинку.



5. Чтобы создавать напряжение и интригу



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



Возьмем для примера этот эпизод с пропускным пунктом охраны:







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



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

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



Наконец, дойдя до пропускного пункта, вы замечаете нарушение паттерна. Солдаты не нападают на вас, но один из них становится на пути к двери, через которую только что вышли 2 человека. Солдаты указывают вам на другую дверь, которую вы не видели, проходя через лабиринт. Нарушение паттерна сбивает вас с толку и побуждает задать себе вопрос: почему вас ведут в другую дверь? Не скрывается ли за ней какая-нибудь угроза?



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

Original source: habrahabr.ru.

https://habrahabr.ru/post/306224/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Метрики против Опыта

Четверг, 21 Июля 2016 г. 16:18 (ссылка)

image



Данная публикация — местами вольный перевод статьи за авторством Julie Zhuo, продукт-дизайнера в Facebook. Приятного чтения.



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



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



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



«Делаем ли мы это просто для получения метрики?»

«Как мы можем сбалансировать полученные цифры и сделать при этом что-то достойное?»

И мой фаворит: «Вы, те, кто управляет данными, на самом деле заботитесь о пользователях и UX?»



Ох! Сильные слова и жгучие обвинения!



Может, хотите продуктивно поговорить о метриках и позитивном опыте? Вот что знаю я.



Не создавайте рамок в стиле «Метрики против Опыта»



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



Сравнивать Метрику и Опыт тоже самое, что сравнивать «углеводы и здоровую пищу». Не стоит пользоваться подобными сравнениями, если хотите начать дискуссию о здоровом питании.



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



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



И наконец, третья причина по которой метрики столь ценны в том, что они помогают сплотить команду вокруг чего-то ясного и ощутимого, благодаря чему люди могут видеть собственные результаты. С чисто материально-технической точки зрения трудно управлять 50 людьми с установкой «мы должны создать что-то крутое!». Конечно, каждый может махать кулаками после драки и кричать «Да! Мы сделали что-то удивительное! Это то, чего мы хотели добиться!», но когда это утро понедельника и команда А появляется в офисе и начинает расхваливать себя, команда Б может отреагировать примерно в таком стиле: «Гм, нет, это на самом деле кусок дерьма». Что вообще происходит? Как четко определить, что есть это самое «что-то крутое?».



Одним из способов решения этой проблемы является построение иерархической лестницы внутри коллектива. Вы можете обозначить конкретное лицо (или перечень лиц) в компании, чтобы те выступали «судьями», что есть «крутое», а что — нет. Если же вы предпочитаете работать без иерархии, то другой доступный вам метод — определение измеримой цели. «Сверхвысокое качество продукта означает, что 50% пользователей обратится к данной „фиче“ еще раз в течении недели». Теперь команда А и команда Б точно знают, к чему они идут изо дня в день и как близко они находятся к этой цели.



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



Плохие решения принимаются во имя «улучшения показателей»



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



Если вы случайно выбрали неверный объект для получения метрики, опираясь на которую вы собираетесь двигаться дальше и развивать свой продукт, в конечном итоге вы можете получить на выходе что-то по-настоящему «вредное» в плане UX. Рассмотрим несколько примеров:



а) «Изначально рейтинг кликов по данной функции составлял 2%. Когда мы внесли изменения, то рейтинг поднялся до 5%! Ура!».



В чем тут проблема? Увеличение кликов по функционалу не говорит нам о том, что UX был на самом деле улучшен. А что если я поменял все ссылки на сайте на «нажмите здесь, чтобы заработать 250 баксов»? Черт подери, клики реально будут ползти вверх! Но в конце концов люди поймут, что я на самом деле не дам им эти 250 баксов и обозлятся на меня. Они перестанут переходить по моим ссылкам, удалят приложение и влепят мне 1 звезду в магазине с припиской «FUUUUUU». И да, именно заглавными буквами. Мой бизнес будет разрушен, моя жизнь превратится в дерьмо. Конец.



б) Люди привыкли тратить на мое приложение 5 минут. Теперь же, после запуска последней введенной функции, они стали тратить всего 3 минуты. Э-э-э, вы чего?



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



с) «Изначально наше приложение с фотками котиков и мемами больше использовали в штате Иллинойс, но теперь у нас больше пользователей в штате Огайо».



Так в чем проблема? Конкретно это не имеет значение и не подобная информация не может являться метрикой, на которую следует обращать внимание и пытаться как-то на нее повлиять.



Конечно, есть важные вещи, которые нельзя легко и точно измерить



Если бы мы могли читать мысли пользователя, то можно было бы теоретически спроектировать идеальный UX. К сожалению, все мы не Джина Грей (телепат из вселенной X-Men, прим.), поэтому нам приходится измерять все, что можно, делать все, чтобы построить обоснованные предположения на тему того, что же нужно людям. Но объем измеряемых данных имеет свои пределы и нам важно помнить об этом. Просто статистика того, что люди делают в вашем продукте не может ничего сказать вам о таких вещах как:



Степень лояльности, ненависти или безразличия к вашему продукту из-за какой-то его конкретной специфической особенности;

Увеличивает ли или уменьшает сбор статистических данных доверие людей к вашему продукту с течением времени;

Как просто и легко ваш продукт воспринимается пользователями;

Как люди видят ваш продукт в сравнении с аналогичными предложениями на рынке;

Какие вещи пользователям хотелось бы изменить, добавить или оставить в этом виде, как есть;

Каков будет уровень интереса к вашему продукту с течением времени.



Ответы на некоторые из поставленных выше вопросов вы можете получить, проведя исследование качества, опросы и собеседования, но ни один из этих инструментов не является совершенным (помните же опросы с предсказаниями о Brexit?). И даже в тех случаях, когда мнение широких масс можно точно измерить (например, степень доверия бренду), трудно понять, какие именно действия и изменения привели к подобной реакции (причиной стал логотип? Или это сделал визуальный редизайн и именно из-за него отношение людей к моему бренду улучшилось?).



Не будучи в состоянии точно измерить вышеописанные позиции, метрики в этих случаях нас подводят. Обратите внимание на следующее:



Понимание цены сложности (Understanding the cost of complexity): каждый раз, когда вы добавляете в свое приложение новую функцию, вполне вероятно, что отслеживаемые вами метрики показывают положительную динамику (в конце концов, до этого момента никто не использовал функционал Х, а теперь все больше и больше людей обращаются к нему. И, кажется, что это не приводит к уменьшению использования функционала Y или Z, так что в целом это похоже на победу). Тем не менее, если вы продолжите добавлять новые функции, в какой то момент ваш продукт станет раздутым. Затем, внезапно, ваш конкурент пойдет вертикально вверх из-за того, что у него будет просто реализован функционал Q, который нравится части аудитории. Это парадокс выбора и размера затрат когнитивных усилий. И мы просто еще не поняли, как это точно измерить.



Понимание силы бренда (Understanding the power of brand): когда компании Apple или Nike выпускают на рынок свой новый продукт, многие склонны покупать его, даже не проводя какого-либо анализа, просто потому, что в прошлом у них был позитивный опыт, связанный с данным брендом. Но тоже самое не сработает, если на рынке появится какой-нибудь выскочка под брендом «Pear» (груша) или «Sike» с эквивалентным продуктом. На общем уровне мы все знаем и понимаем это. Тем не менее, нам трудно оценить силу бренда и превратить ее в число, которое мы сможем ежедневно отслеживать. Трудно понять, какое именно из тысячи действий повлияет на имидж компании, каковы будут выгоды и потери от от принятия того или иного решения.



Сила игры по-крупному (The power of big bets): нет, метрики не могут сказать вам, какое смелое действие нужно совершить, чтобы в будущем выиграть. Представьте себе 2008 год, когда смартфоны только начали появляться. Глядя на метрики своего сайта вы бы увидели крошечный кусочек трафика, приходящий с мобильных устройств. Вы бы, возможно, пришли к выводу, что в оптимизацию под мобильные устройства не стоит вкладывать сил, потому что это слишком небольшая часть вашей аудитории. Сегодня же мы пониманием дальновидность тех, кто сделал ставку именно на мобильный сегмент и кто сейчас пожинает лавры. Ни одна экспертиза текущего поведения пользователей не может точно сказать, в какую сторону вам нужно «прыгнуть». Стратегическое, долгосрочное планирование по-прежнему требует того же, чего и всегда: доверять своему нутру.



Некоторые правила чистоплотных метрик



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



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



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



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



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



Также существуют данные, которые можно назвать «контрметрикой». Если вы смотрите на цифры, которые показывают хороший результат, спросите себя: «с какой еще информацией я могу ознакомиться, чтобы убедить себя в том, что эти результаты не настолько хороши, как кажутся?». И эта информация называется контрметрикой и каждая успешная метрика должна ее иметь. Например, посмотрите на рейтинг кликов, и на то, как быстро они показывают отскок. Или на числа продаж в сравнении с количеством возвратов или отмен. Гораздо лучше быть параноиком в плане интерпретации данных, ведь так можно быстро выловить ошибки и скорректировать собственную стратегию. Не попадитесь в ловушку предвзятости, где вы просто ищете сигналы для того, чтобы подтвердить собственные ожидания.



Используйте качественные исследования, чтобы получить ответы. Используйте количественные данные, которые говорят вам, что люди делали в приложении, в паре с качественными исследованиями, которые дают вам представление о людских эмоциях и чувствах. Проведите юзабилити-тесты, используйте фокус-группы, запустите опросы и узнайте, что стоит за поведением, которое вы наблюдаете.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306154/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как подходить к созданию сложного продукта: 3 совета разработчикам

Суббота, 16 Июля 2016 г. 11:33 (ссылка)





Мы в «Латере» уже много лет занимаемся разработкой биллинга для операторов связи и развиваем сервис для управления выездными сотрудниками «Планадо».



Биллинг — это сложный продукт, работа над которым имеет свои особенности. Во-первых, это узкоспециализированный инструмент enterprise-уровня, который внедряется сотнями экземпляров, а не десятками и сотнями тысяч. Во-вторых, система должна работать в режиме 24x7x365. И самое главное — именно биллинг считает деньги, а значит это критически важный элемент инфраструктуры любой компании.



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



Сразу думайте о будущих доработках



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



Иллюстрация из близкой нам сферы телекоммуникаций — разные операторы требуют разных возможностей биллинга. Свои особенности телеком-отрасли могут быть в разных регионах — к примеру, в Норильске и Магадане нет проводных каналов связи, доступен только спутник. Поэтому доступ в интернет здесь очень дорогой и до сих пор в ходу тарифы с квотами трафика. Такая же ситуация в некоторых странах Центральной Азии (например, Афганистан) и Африки (Нигерия).



Может иметь значение и размер абонентской базы — процессы небольшого и федерального провайдера строятся по-разному.



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



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



Главный секрет того, как избежать таких ошибок, прост — нужно серьезно проанализировать предметную область, прежде чем предпринять какие-то действия. К примеру, мы в «Латере» в случае необходимости каких-то крупных доработок тратим до 20% времени на общение с клиентами, погружение в их бизнес-задачу, изучение общепринятой практики и разработку требований к функциональности. Если же ограничивать доработку только тем, что нужно конкретному заказчику, для других она будет бесполезной. А для серийного программного продукта это гарантированные убытки.



Не пытайтесь объять необъятное



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



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



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



Например, многие клиенты просили нас автоматизировать процесс подключения нового абонента в биллинге. Они привыкли к этому, заявок было много, и мы пошли у них на поводу. Уже через год мы поняли, что ошиблись: функциональность оказалась слишком ограниченной, а написанный код усложнил решение биллинговых задач. Изучив предметную область, мы пришли к правильному решению, вынесли обработку заявок в отдельный продукт и сделали его опенсорсным.



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



Будьте готовы к многократному переписыванию кода



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



Понять, где именно необходимы доработки, может быть очень нелегко. Пример такой ситуации — разработка функциональности системных событий нашего биллинга «Гидра». Под такими событиями подразумевается какое-то изменение важных параметров, которое требует от системы определенных действий — например, при снижении остатка средств на счете до нуля, абоненту следует отключить доступ к услуге. Очевидно, что событие в данном случае должно нести в себе какую-то информацию об абоненте, например его идентификатор, MAC-адрес и т.п. Все это казалось правильным и логичным на этапе проектирования, однако потом начались проблемы. К примеру, при определенном стечении обстоятельств система отрабатывала не так, как ожидалось в предметной области: кто-то поменял код услуги, а он использовался в команде на подключение доступа, должны ли пересоздаться события по всем абонентам?



Оказалось, что в реализации событий была заложена бомба замедленного действия. Код этого модуля со временем стал очень сложным, а проблема отсутствия доступа возникала постоянно, причем известно о ней становилось не сразу — события не пересоздавались, пока не происходило что-то непосредственно с этим абонентом, а когда это происходило, нужно было вызывать медиума, чтобы определить причины. Разработчики боялись дотрагиваться до этого кода, чтобы починив одно не сломать другое.



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



Заключение



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



Другие статьи по теме ИТ-инфраструктуры от команды «Латеры»:



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305776/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Анализ обнаружения обфусцированных вирусов мобильными антивирусными приложениями на платформе Android

Пятница, 15 Июля 2016 г. 12:39 (ссылка)

Команда УЦСБ провела независимое исследование для того, чтобы протестировать работу популярных антивирусных приложений для Android. С результатами этого исследования я делилась на конференции phdays VI, но хотелось бы более подробно остановиться на применении обфускаторов для обхода механизмов обнаружения вирусов.

Читать дальше →

https://habrahabr.ru/post/305730/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Типичные ошибки начинающего технического директора в ИТ — мнения экспертов

Четверг, 14 Июля 2016 г. 19:04 (ссылка)



Изображение с сайта tech.co



От некоторых сотрудников ИТ-компаний до сих пор можно услышать такую реплику: «Я не совсем понимаю точное значение должности Технический директор». Как отметил в предельно простой форме один из пользователей «Тостера», «CTO — технический человек, который что-то понимает в бизнесе». Если рассматривать это понятие чуть шире, то можно сказать, что он балансирует на стыке между разработкой ИТ-продуктов с командой технических специалистов и принятием бизнес-решений совместно с менеджерами.



Соответственно, для специалистов, желающих занять позицию технического директора в ИТ, существует, как минимум два пути:




  1. стандартный — «Developer -> Senior -> Team lead -> CTO»;

  2. гуманитарный – «PM -> Senior PM -> CTO».



Безусловно, в случае второго варианта понимать технические нюансы техническому директору может быть сложнее.



Но достигнув желаемого, в целом, опытный специалист переходит как бы в разряд начинающих. Он становится этаким Junior-CTO и сталкивается с новыми вызовами.



О том, какие ошибки и подводные камни ожидают новоиспеченных технических директоров в ИТ-сфере, мы попросили рассказать экспертов отрасли.



Виктор Шабуров, предприниматель, инвестор и один из основателей компаний Looksery Inc., Handster Inc. и SPB Software



Насколько часто начинающий технический директор ошибается с дедлайнами?



Это типичная ошибка почти всех СТО из СНГ — стараются показать себя наиболее эффективными, что умеют все быстро делать. Я даже не борюсь с этим — бесполезно. Просто удваиваю их сроки в своих оценках.



Какие случаи можете вспомнить?



Да это 100% случаев. Иногда удается объяснить СТО, что ему самому надо сроки удваивать, когда наверх даешь, но команде не говорить. Команду гнать по начальному плану — тогда получается вовремя все сделать.



Насколько это важно для вас?



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



Насколько часто начинающий технический директор ошибается с постановкой и распределением задач среди сотрудников?



В принципе мне везло всегда работать с хорошими СТО. Они наверно часто ошибались, но хорошо следили. Через пару дней видно, если задачи распределены неправильно, и они эту проблему решали.



Насколько это важно для вас?



Если СТО внимательно следит за работой — это не проблема, быстро можно исправить.



Какие специалисты больше страдают от ошибок технического директора? Тестировщики, разработчики, проект-менеджеры? Какие случаи можете вспомнить?



Тьфу-тьфу — все СТО, с которыми я работал были отличными. Особенно везло СТО Handster (а потом Opera Software) Алексу Решетько — ему сначала нужно было запустить Hewlett Packard Appstore на Новый Год, а позже Opera Appstore снова на Новый Год, оба проекта за пару месяцев. Вся команда стояла на ушах в праздники, никто не пил и не спал.



Выкатили аппсторы на многомиллионную базу, было очень страшно оба раза — но запуски прошли отлично. Opera Appstore за год вырос до 100М ежемесячных пользователей.



Воспринимаете ли вы ошибки начинающего технического директора, как просчеты старшего товарища или как некомпетентность руководителя? Сможет /должна ли команда «воспитывать/выращивать» технического директора?



Техническую компетенцию человек может набрать. Но ответственность должна быть изначально — если ее нет, надо сразу менять человека, это не выращивается. Обычно это видно на интервью.



Какие случаи можете вспомнить?



Наиболее яркий случай – это, наверное, Юрий Монастыршин, который руководил технической стороной Looksery. Ответственность была очень высокая и правильный подход ко всем проблемам — их надо решать сейчас.



Для меня до сих пор загадка, как он (будучи студентом 5-го курса) справился с созданием проекта, которым сейчас пользуются сотни миллионов людей и который генерирует несколько миллиардов просмотров в день.



Дмитрий Шашлов, iOS-разработчик:



Насколько часто начинающий технический директор ошибается с дедлайнами? Какие случаи можете вспомнить? Насколько это важно для вас?



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



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



Насколько часто начинающий технический директор ошибается с постановкой и распределением задач среди сотрудников? Какие случаи можете вспомнить? Насколько это важно для вас?



Команды, в которых мне доводилось больше всего работать на 80% состоят из технарей до 30, среди которых достаточно распространены следующие реакции на постановку задачи:



— A. «Я не уверенно себя чувствую в задаче, подобную которой никогда раньше не делал»



— B. «Сверстать сайт? Отлично, я заодно разберусь как парсить на Perl'e»



— C. «Делать джойны по таблицам — для малолеток, дайте мне уже какую-нибудь нормальную задачу!»



— D. «В форме будет валидатор? Если нет — 8 часов, если будет, то 10-12.»



А дальше — конструктор: там, где нужно исследовать силами B, будет нерационально использовать D, в силу своего рационального расчета; если дать в помощь A товарища C — но и первый будет заряжен, и у второго зудеть перестанет. Так что, наверное, самое важное не быть безучастным, и применить смекалку.



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



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



Тут многое зависит от организационного уровня, на котором принимаются решения — в различных ситуациях могут «пострадать» как отдельные сотрудники (принял решение, близкое себе, невзирая на контекст, в котором требуется решение), так и вся команда (на просчет технического задания было передано недостаточное количество исходных данных, не было обращено внимание на отдельные важные для реализации моменты, менеджмент производился без понимания необходимой последовательно реализации продукта).



Но, безусловно, важно не уметь не совершать ошибок, а уметь извлекать из них правильные выводы: в чем заключалась ошибка планирования, кому из сотрудников нужно давать больше/меньше свободы принятия решения, каким тестом нужно в первую очередь проверять гипотезу реализации и тд.



Воспринимаете ли вы ошибки начинающего технического директора, как просчеты старшего товарища или как некомпетентность руководителя?



Оценка сугубо субъективная, все зависит от того, какую роль CTO играет в том, над чем ты работаешь: вряд ли ты будешь относиться как к старшему товарищу к мистеру «подай да принеси»; напротив, когда у тебя сформировано ощущение, что CTO — тоже участник процесса и польза, которую он привносит непосредственно в твой производственный процесс — осязаема, и, что немаловажно, ты, как технический сотрудник, ощущаешь что в «этом джедае больше силы» — то проникаешься к такому руководителю уважением и начинаешь воспринимать ваши неудачи — как общие. Есть, правда, риск повестись на обложку, а потом сильно обломаться — тогда это опыт в собственную копилку умения читать людей.



Сможет /должна ли команда «воспитывать/выращивать» технического директора? Какие случаи можете вспомнить?



Скорее нет, чем да. Но сделать его сильнее, может только команда.



Виктор Rpsl Диктор. Человек-оркестр.



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



Насколько часто начинающий технический директор ошибается с дедлайнами? Какие случаи можете вспомнить? Насколько это важно для вас?



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



Насколько часто начинающий технический директор ошибается с постановкой и распределением задач среди сотрудников? Какие случаи можете вспомнить? Насколько это важно для вас?



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



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



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



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



Из своей практики у меня в памяти всплывает только один момент которому уже много лет, я помню, как уговаривал своего технического директора поменять стандарты и перейти на git с svn и на idea с netbeans. Все мои попытки разбивались о стену непонимания и утверждения, что «эти инструменты не дают ничего нового, абсолютно то же самое можно делать в текущих, а значит, в смене платформ нет смысла».



Воспринимаете ли вы ошибки начинающего технического директора, как просчеты старшего товарища или как некомпетентность руководителя?



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



Сможет /должна ли команда «воспитывать/выращивать» технического директора? Какие случаи можете вспомнить?



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



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



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



Спасибо за внимание.



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

Original source: habrahabr.ru.

https://habrahabr.ru/post/305686/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Кнут и пряник: как современные технологии помогают руководству контролировать рабочий процесс, и что это дает сотрудника

Четверг, 14 Июля 2016 г. 09:43 (ссылка)





В мае нынешнего года компания Натальи Касперской InfoWatch предложила инновационную систему контроля за хранением корпоративных тайн. Специалисты ИТ-компании разработали «прослушку», позволяющую перехватывать и анализировать разговоры сотрудников по рабочим мобильным телефонам. За инициативой последовало множество вопросов, главные из которых — зачем руководители внедряют технологии контроля рабочего процесса, и приносят ли новые методики оценки производительности пользу сотрудникам?



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



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



Трудовая дисциплина и исполнение служебных обязанностей: электронные системы организации рабочего процесса







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



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



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



«Теперь, если кто-либо из сотрудников не выходит на работу, система учёта рабочего времени фиксирует это», — делится опытом работы с CrocoTime начальник отдела кадров B2B-Center Алина Искендерова. — «Статистика CrocoTime обновляется раз в пять минут, и мы можем оперативно связаться с руководителем отдела и выяснить причину отсутствия подчинённого». Наряду с учетом «посещаемости», ресурсы помогают определить, кто из сотрудников сидит в социальных сетях или играет в онлайн-игры в рабочее время.



Наибольшую пользу внедрение электронных системы организации и контроля рабочего процесса принесет руководителям крупных компаний. По данным аналитиков сервиса «Стахановец», в организациях, штат которых превышает 50 человек, сотрудники тратят на решение деловых задач только 38% рабочего времени, так как личный вклад каждого отдельного члена команды сложно определить.



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



Контроль качества работы выездных сотрудников: системы FSM (field service management)







С рядом сложностей сталкиваются и руководители компании, чьи сотрудники выезжают к клиентам для оказания услуг (например, для сборки мебели, ремонтных и монтажных работ, уборки помещений). В условиях офиса можно контролировать работу подчиненных лично, но следить за несколькими выездными бригадами удаленно гораздо сложнее. Эффективным решением этой проблемы может стать сервис управления выездными сотрудниками Planado, который как заявляется, способен повысить производительность труда мобильных бригад более чем на 30%.



Planado не только облегчает коммуникацию между руководителем и выездными сотрудниками, но и помогает бригадам придерживаться единых стандартов работы, что значительно повышает качество оказываемых услуг. Кроме того, ресурс позволяет следить за «невидимыми работниками»: благодаря Planado сотрудники не смогут в течение дня заниматься своими делами под предлогом «затянувшейся работы». Поможет ресурс и тем руководителям, которые подозревают свои сотрудников в подработке «на стороне» в рабочее время, — благодаря грамотной оптимизации задач, у нечестных работников просто не останется времени на то, чтобы выполнять личные заказы.



« [...] Проблема актуальна в разных областях: у компаний, которые устанавливают окна, обслуживают охранно-пожарную сигнализацию, занимаются клинингом, сбором мебели, ремонтом техники на дому и др. У всех организаций, использующих выездных сотрудников, одни и те же проблемы, которые можно решить внедрением новых технологий — замечает руководитель Planado Вадим Захариков. — Эффективность инструментов для управления доказана различными исследованиями. Судя по нашему первому опыту, работает это и в России — в среднем внедрение приложения позволяет повысить продуктивность выездных сотрудников на 31%».



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



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



Безопасное хранение корпоративной информации: DLP-системы







По данным масштабного исследования компании Zecurion, максимальный размер ущерба, который понесла отечественная компания в результате «слива» корпоративных тайн, составил в $30 млн. Средний же финансовый ущерб крупных коммерческих организаций от одной утечки — $820 тыс. Чаще всего инсайдеры похищают и продают персональные данные сотрудников и акционеров (74,3%), списки клиентов и поставщиков (70,2%), а также персональные данные клиентов (69,2%).



Защитить корпоративные тайные помогут DLP (Data Leak Prevention) — системы. Чаще всего они выполняют сразу несколько задач — отслеживают и анализируют деловую и личную переписку с рабочих компьютеров, «перехватывают» сообщения в социальных сетях и мессенджерах, фиксируют копирование данных в облако или на внешние носители, проверяют историю запросов в браузере. Отдельное внимание уделяется переводу внутрикорпоративной информации на бумажные носители. Невероятно, но в 10% случаев краж производственных данных инсайдеры просто распечатывают необходимое на офисном принтере.



«Мы не можем контролировать всех сотрудников, мониторим в первую очередь группы риска — 85% нарушений и утечек приходится на увольняющихся сотрудников, — утверждает руководитель аналитической службы Solar Security Галина Рябова. По мнению эксперта, в «список подозрения» должны попадать и сотрудники, чьи расходы очевидно не совпадают с зарплатой. Например, те, кто неожиданно для коллег приобретает автомобиль или недвижимость.



Контроль за поведением в социальных сетях и запрет на мессенджеры



Особое внимание сотрудники служб безопасности крупных компаний уделяют и содержанию страничек сотрудников в социальных сетях. «Пост сотрудника может разрушить репутацию компании, если он напишет о задержке зарплаты, сорванной сделке или готовящихся сокращениях,» — уверен основатель компании Sidorin Lab Дмитрий Сидорин — «сейчас каждый сотрудник в социальной сети, указавший название своей компании, является носителем торговой марки».



Однако, заинтересованные в сохранении деловой репутации руководители интересуются не только постами о компании и селфи с рабочего места (на них по невнимательности нередко запечатлевают рабочую документацию), но и списками «друзей» и подписками подчиненных. Если в друзьях присутствуют сотрудники конкурирующих фирм и журналисты из профильных изданий, работник может попасть в «группу риска».



Немало подозрений вызывает и деловая переписка в мессенджерах. Так, руководитель компании «Мегаплан» Сергей Козлов предпочел закрыть доступ сотрудников к Telegram, чтобы «история общения и обсуждения оставалась в компании».



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



Пряник: как избежать негативной реакции сотрудников



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



Главным механизмом борьбы с негативной реакцией эксперты считают открытый и честный диалог с коллективом. «Желательно, конечно, провести анкетирование среди сотрудников и дать возможность им высказаться, чтобы точно понять, чем именно они не довольны», — советует Сергей Ожегов, коммерческий директор компания SearchInform.



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



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



Для того, чтобы внедрение новых механизмов контроля рабочего процесса прошло «безболезненно» для коллектива, необходимо:



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

  2. Объяснить, что нововведение принесет пользу не только руководству, но и коллективу (сотрудники, привыкшие прятаться за спинами коллег, перестанут «тормозить» работу команды, наиболее трудолюбивых и ответственных ждет награда).

  3. Быть готовым неоднократно ответить на вопросы подчиненных о нововведении.

  4. Разработать программы поощрения для сотрудников, демонстрирующих в новых условиях наибольшую производительность труда (премии и прибавки к заработной плате).

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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305640/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ASSuk

Думаю начать делать один сайт... пока что прорабатываю тематику.

Среда, 13 Июля 2016 г. 11:00 (ссылка)


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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Onem

Ка-52К «Катран»: коротко о главном Политикус InfoPolk.ru

Среда, 13 Июля 2016 г. 04:03 (ссылка)
infopolk.ru/1/U/army/80434-...00fc74687c

Ка-52К «Катран»: коротко о главном


Разработка палубной версии разведывательно-ударного вертолета Ка-52 началась в 2011-м году, после того как на вооружение ВВС России поступили первые «Аллигаторы» ...

Комментарии (0)КомментироватьВ цитатник или сообщество
Natalya_Alexandr

Изготовление каталогов

Вторник, 12 Июля 2016 г. 14:24 (ссылка)


        Сейчас всё более популярным становится использование в компаниях и различных организациях каталогов. Что собой представляет каталог. Это так называемое справочное издание, с помощью которого компании или фирмы могут рассказать о своей продукции или товарах.  Ведь, когда вы открываете такой каталог, вы можете не только рассмотреть весь ассортимент представляемой продукции, но и узнать более детально об её составляющих, стоимости и характеристиках. Поэтому каталоги сейчас есть почти везде: в магазинах, кафе, ресторанах, супермаркетах и так далее.












h (250x158, 52Kb)

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


          Крепление каталогов также может быть разнообразным: на скобах, клеевым методом и на пластиковой пружине. Всё зависит от объёма и формата каталога, ну и, конечно, денежных средств, вложенных в его разработку. Необходимо заметить, что с таким ответственным заданием, как разработка каталога, может справиться не каждая типография, поэтому доверять этот заказ можно только проверенной компании с многолетним опытом работы и большим количеством постоянных клиентов, иначе вас может ожидать большое разочарование. Узнать более подробно об изготовлении каталогов можно по ссылке ckprint.net/reklamnaia-poligrafia/9-izgotovlenie-katalogov.html.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<разработка - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda