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


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

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

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

Разработка микро-учётной системы на lua, часть шестая. И снова модуль управления базой

Среда, 01 Июня 2016 г. 19:26 (ссылка)

В связи с высказаным мной предположением в части 3-й и 4-й я решил модифицировать модуль базы. Изменение этого модуля повлекло модификацию всех исполнительных. Но это того стоило. Модификация состоит в том, что для вызова СУБД — зависимых запросов можно настроить однотипные процедуры, принимающие параметры на входе.



Оассмотрим функцию database.select_from_where(select, from, where), которая часто используется в процедурах для получения табличной информации:

function database.select_from_where(select, from, where)

text = "SELECT " .. select .. " FROM " .. from

if where ~= nil then
text = text .. " WHERE " .. where .. " ;"
else
text = text .. " ;"
end

query = database.link()
thread = query:execute(text)
result = thread:fetch({}, "a")
return result

end


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

https://habrahabr.ru/post/302406/

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

Разработка микро-учётной системы на lua, часть пятая. Модуль управления

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

Модуль управления является frontend — узлом проекта. Скрипт cvs.lua взаимодействует с исполнительными модулями, которые являются бизнес — логикой проекта.



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



Модуль cvs.lua: Читать дальше →

https://habrahabr.ru/post/302402/

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

Разработка микро-учётной системы на lua, часть четвёртая. Модуль доступа к базе

Пятница, 27 Мая 2016 г. 16:30 (ссылка)


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

image

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

https://habrahabr.ru/post/302004/

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

Разработка микро-учётной системы на lua, часть третья. Lua и взаимодействие модулей

Четверг, 26 Мая 2016 г. 21:03 (ссылка)


Помните, в прошлой части была схема взаимодействия модулей? Теперь пришло время рассмотреть её подробнее:



image



Для первоначального обучения всем желающим есть учебник «Язык Lua за 15 минут». Здесь я постараюсь рассматривать детали, которые относятся к проекту и не упоминаются в учебниках — только в справочниках и форумах (по возможности).



Для понимания кода нужно принять во внимание следующие особенности разработки на Lua:


  • Язык разрабатывался, как система обработки семантических и числовых массивов данных.

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

  • И самое главное — практически все виды сложных данных представляют собой табличные области. В прямом смысле!

  • Таким образом, опять-таки, все усложнённые объекты представляют собой так называемые метатаблицы — это массивы, которые хранят в себе описание и информацию экземпляра. Вложенность метатаблиц может быть поистине феерической!



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

https://habrahabr.ru/post/301920/

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

[Перевод] Что делает программное обеспечение качественным?

Среда, 16 Марта 2016 г. 21:26 (ссылка)

image

КДПВ



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



У вас возникает вопрос: какие качества программного обеспечения приводят разработчика к успеху или к неудаче? Как я могу улучшить свой софт и помочь бо

https://habrahabr.ru/post/279459/

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

Сопротивляйтесь добавлению в проект новых библиотек

Пятница, 15 Января 2016 г. 12:03 (ссылка)


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



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



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

http://habrahabr.ru/post/275159/

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

Компания «БитПрофи» определила бизнес-тенденции будущего в разработке мобильных приложений

Вторник, 27 Октября 2015 г. 13:31 (ссылка)


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


Одним из самых динамично развивающихся сегментов мирового рынка ИТ является рынок программного обеспечения, рост которого в последние несколько лет ежегодно превышал 6 %. Больше половины общего объема сегмента формируют разные категории приложений, остальное приходится на системное ПО и средства разработки. Согласно исследованиям компании IDC, расходы в России на программное обеспечение с 2014 года по 2018 годы вырастут с 5 до 7 млрд долларов. Кроме того, с апреля 2014 года действует государственный проект, утверждающий стандарт для российских разработчиков программного обеспечения. Этот факт говорит о прочном формировании ИТ-рынка страны.




 





Из самых востребованных направлений — разработка заказного программного обеспечения на заказ, особенно на основе продуктов с открытым кодом. Усилился интерес к решениям, автоматизирующим торговлю, мобильным и портальным решениям, реализации ИБ и бизнес-аналитики, преимущественно в сегменте защиты от мошенников и DDoS-атак, с возможностью оптимизации трафика приложений, диагностики производительности ИТ-инфраструктуры.



Тенденции будущего на рынке мобильных приложений



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



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



Ознакомиться с предложениями компании «БитПрофи» по разработке программного обеспечения на заказ можно на сайте компании.



Контакты:



+7 (495) 662-98-93

info@bitprofi.r

u


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

Как Cisco Security Ninja научили 20 тысяч сотрудников безопасному программированию?

Воскресенье, 19 Октября 2015 г. 02:06 (ссылка)

Когда вы слышите словосочетание “повышение осведомленности в области информационной безопасности”, то что вам первым приходит на ум? Обучение пользователей не открывать письма от посторонних и не кликать на фишинговые ссылки? Обучение способам распознавания социального инжиниринга? Отслеживание, чтобы никто посторонний не зашел в офис, как будто бы он с вами? У нас в Cisco такая программа тоже есть и мы тоже регулярно проходим соответствующее обучение. Но сегодня мне бы хотелось рассказать о другой нашей добровольной программе повышения осведомленности, которая была создана менее чем за полгода командой из всего четырех человек с бюджетом менее 50 тысяч долларов. Обратите внимание еще раз. Добровальная программа! Создана четырьмя людьми! Меньше чем за полгода! Всего за 50 тысяч долларов! А прошло обучение и успешно сдало экзамен по этой программе свыше 20 тысяч сотрудников Cisco — инженеров и разработчиков.





История создания



Идея создания данной инициативы пришла в мае 2012-го года, когда на конференции Security Development, компания Adobe рассказала о своей программе Adobe’s Security Training Program. Тогда нам пришла в голову мысль, почему бы и в Cisco не создать такую программу. Тем более, что проблема давно назрела. Программы обучения разработчиков как таковой не было. Принципы безопасного программирования (Cisco Secure Development Lifecysle, CSDL) знали многие, но как их применить на практике для снижения числа ошибок и потенциальных уязвимостей, понимали далеко не все. Тем более, что разработчики по традиции мало задумывались о том, как развивается мир безопаности по ту сторону баррикад, как действуют злоумышленники, что они могут и куда направлены их устремления?



Идея идеей, но нам не хотелось идти по проторенной дороге с организацией еще одного тренинга по безопасности. Все-таки, чего скрывать, многие обучающие программы, даже корпоративные, даже бесплатные, рассматриваются многими сотрудниками как наказание и неизбежное зло. При таком отношении большого эффекта ждать не стоило. Поэтому мы решили нашу практику в безопасном программировании и создании доверенных систем, которая у нас активно развивалась последние годы, объединить с опытом работы нашего подразделения по реагированию на инциденты в наших же продуктах (Cisco Product Security Incident Response Team, PSIRT). И наложить на эту комбинацию игровой компонент, вовлекая работников по собственной воле в увлекательную игру, в которой можно было бы зарабатывать очки, получать признание у окружающих и, попутно и ненавязчиво, получать новые знания и компетенции. Как известно, информация, полученная в игровой форме, запоминается на гораздо дольший срок, чем обычная теория, даже и облеченная красивыми презентациями и роликами.



Сказано — сделано. За основу была взята идея обучения восточным единоборствам, с ее комбинацией изучения философии и техник, обучением в зале (так называемом додзё) и в жизни, прохождением через различные степени (пояса), отображающим определенные достижения обучаемого. Участники нашей программы получили название Cisco Security Ninja. Почему ниндзя? Наверное потому что на протяжении многих десятилетий или даже столетий вокруг этих японских воинов сложилось множество легенд и их имя обросло множеством тайн. Приобщение к “тайне” CSDL служит отличительным знаком разработчиков и инженеров, прошедших соответствующее обучение.



Девизом данной инициативы стало перефразированное высказывание: “Безопасность это путь, а не точка назначения”.







Пояса Cisco Security Ninja



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







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



Зеленый пояс подразумевал получение расширенных знаний по тем или иным концепциям безопасности, а также практическое применение принципов и практик безопасности в зависимости от роли обучаемого. Их мы выделили шесть — менеджер по продукту, менеджер по программам, менеджер, инженер по дизайну, инженер по разработке, инженер по тестированию. Для получение зеленого пояса необходимо было пройти уже около 50-ти модулей — начиная от изучения различных атак (XSS, CSRF, SQL Injection, социальный инжиниринг, атаки на аппаратном уровне) и CSDL (моделирование угроз, поиск уязвимостей, анализ кода, типовые ошибки программирования на C) до основ защиты Linux, изучения Secure Boot, SSL, управления цепочками поставок и “менеджерских” тем.







Последующие три пояса подразумевали уже не изучение каких-либо теоретических или практических тем, а содействие внедрению практик защищенного программирования в деятельности Cisco. И чем выше пояс, тем больше таких действий необходимо реализовывать. Чтобы исключить неопределенность в процессе завоевывания “высших” поясов, все активности, которые кандидаты на получение синего/коричневого/черного пояса, должны были совершить, поделены на 4 группы — изобретение (например, создание полезного инструмента или процесса или ведение community), обучение (менторинг, проведение или разработка курсов, выступления), исследование (анализ какой-либо проблемы, участие во внутренней рабочей группе или комитете, разработка какой-либо функции безопасности) и реализация (тест, фича, CSDL-процесс и т.п.).



За каждое действие насчитываются определенные баллы, количество которых зависит от временных затрат (1 балл = 1 час) и масштаба активности (только внутри команды, межкомандная активность, внешняя и т.п.). Затем эти баллы суммируются и в зависимости от итоговой суммы присваивается та или иная степень. Например, для получения синего пояса достаточно “заработать” всего 75 баллов, а для черного нужно уже не менее 400 баллов из всех четырех выше описанных групп активностей. Черный пояс — это высшая ступень не только в восточным единоборствах, но и в программе Cisco Security Ninja. Он означает признание как внутри, так и снаружи Cisco.







Программа Cisco Security Ninja в цифрах



Мы запустили программу в декабре 2012-го года, попросив некоторых коллег “попробовать”. Получив положительные отклики, в феврале 2013-го года программа Cisco Security Ninja стартовала официально. В декабре 2013-го года к программе начального обучения на “белый” пояс была добавлена расширенная программа (на “зеленый” пояс), а спустя еще несколько месяцев, мы добавили обучение по ролям. Декабрь 2014-го года ознаменовался запуском оставшихся трех программ для получения синего, коричневого и черного поясов.



В 2014-м году программа получила поддержку на уровне руководства компании, которое стало настойчиво рекомендовать всем заинтересованным лицам получить, как минимум, белый пояс. При этом стоит отметить, что до сегодняшнего дня, эта программа не является обязательной для сотрудников, которые сугубо добровольно присоединяются к ней. В марте 2015-го года мы достигли границы в 20000 сотрудников, получивших свой пояс, из которых 47 получили черный пояс, 22 — коричневый, 72 — синий, 2640 — зеленый (среди них и я).



Додзё для тренировок и экзаменов



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







Геймификация



Один из важнейших элементов программы, позволившей, вовлечь в нее свыше 20 тысяч человек, это геймификация, которая достигалась за счет различных элементов:


  • Метафоры ИБ, с помощью которых в забавной и юмористической форме иллюстрировались ключевые концепции и принципы безопасности и безопасного программирования.

  • Комиксы “Little Ninja”, состоящие из 3-х иллюстраций, разъясняющих те или иные положения курса обучения.








  • Забавные клипы “We are all security ninja”, в которых наши сотрудники в костюмах ниндзя случайно застаются за выполнением ежедневных дел (в кафе, в спортзале, в отпуске, на телефонном звонке и др.).








  • “Поп-идол” — известные внутри или за пределами компании люди, которые высказывались по тем или иным вопросам ИБ









Вообще геймификация — очень интересный способ донесения тематики информационной безопасности. У нас им часто пользуются в компании. Тут и стенды по ИБ, и флеш-игры, и игры для смартфонов, и проведение CTF, и многое другое.



Признание



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







Ключевые факторы успеха



За прошедшие почти три года мы смогли сформулировать 10 критериев успеха нашей программы:


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








  2. Когорта экспертов. Именно они должны создавать контент, а возможно и участвовать в его записи.

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

  4. Вирусный маркетинг. Он позволяет вовлекать в процесс распространения информации о программе самих сотрудников, которые с радостью делятся с друзьями “прикольной фишкой” и “прикосновением к тайне”.

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








  6. Соревнование. Руководители любят конкурировать между собой — дайте им такую возможность, запустив сайт со статистикой по их подчиненным; они сами будут мотивировать свои подразделения быть лучше.

  7. Ломайте правила. Когда мы запускали программу Cisco Security Ninja, мы не знали никаких правил по проведению классических тренингов. Мы делали то, что считали нужным и делали это весело, с шутками и прибаутками. Люди это чувствуют и легче вовлекаются в тренинг с элементами игры.

  8. Креативные люди. Запуск такой программы — это не задача “для галочки”. Тут не помогут люди, которые делают что-то из под палки и люди, незаинтересованные в результате. Только креативный подход помог нам с минимум ресурсов сделать то, что мы сделали.

  9. Вовлечение руководства. Ну тут лишних объяснений не нужно.








  10. Геймификация. Мы сделали интерфейс, который показывал движение, помогал достигать большего, вовлекал в игру. Людям нравилось пользоваться созданным для них додзё.





В качестве заключения



Реализованная нами программа Cisco Security Ninja позволила решить сразу несколько задач, среди которых не только вовлечение 20 тысяч сотрудников в процесс обеспечения информационной безопасности нашей продукции, но и повышение уровня защищенности наших решений. Можно ли повторить данную программу в другой организации? В таком же виде врядли. Все-таки культуры, уровни зрелости, да и сами компании могут сильно отличаться друг от друга. Но ключевые факторы успеха будут едины для всех. Главное не сидеть на месте!



И помните: безопасность — это движение, а не точка назначения!



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

http://habrahabr.ru/post/268999/

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

Долгострой в разработке ПО: о проблемах управления требованиями

Четверг, 27 Августа 2015 г. 15:17 (ссылка)

Чем грозит долгострой в разработке и с какими трудностями предстоит столкнуться на этом пути? Как бизнес-аналитик компании, которая 15 лет занимается разработкой и поддержкой одного продукта (СЭД), я решила поделиться своими мыслями и примерами из практики. Проблематика управления требованиями в любых программных продуктах с длительным периодом реализации – актуальный вопрос для аналитиков, руководителей проектов и владельцев продуктов. И, возможно, для непосредственных партнёров и заказчиков Docsvision, ожидающих выхода новых версий и заинтересованных в появлении новой функциональности.







К чему приводят гонки за сроками и когда гибкие методологии не подходят



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

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







Как правило, в краткосрочном проекте нет возможности реализовать большой объём новой функциональности при подержании должного уровня качества, поэтому зачастую заказчики не видят для себя выгоды в переходе на новую версию (любое обновление содержит определенную долю риска, и они задумываются, стоит ли это того?). А для вендора любой релиз — дорогостоящее удовольствие, поскольку полноценная версия – это комплект инсталляции, документации, проведение тестов производительности, регрессионное тестирование, тестирование обновления и совместимости и ещё целый комплекс мер, которые нужно успеть в сравнительно небольшие сроки. Возвращаясь к картинке выше, мы попадаем на пересечения Качественно-Быстро или Быстро-Дёшево. Поскольку ресурсы не безграничны, это будет именно второе пересечение (читай, криво). Напрашивается вывод: частое обновление версии продукта невыгодно обеим сторонам.



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



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



Методологии разработки



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



Я не открою Америку, если скажу, что в чистом виде ту или иную методологию никто не использует. Что касается проекта разработки Платформы, то могу сказать, что в последнее время у нас используется своя собственная, смешанная методология. Это может стать темой для отдельной статьи, в рамках же данной стоит отметить, что это в какой-то мере Waterfall с элементами Agile (да, бывает и такое!): с одной стороны, четко определены стадии проекта в долгосрочной перспективе, присутствует подробная проектная документация для каждого этапа, качество имеет первоочерёдный приоритет по сравнению с ресурсами и временем, и всё это – неотъемлемые черты каскадной модели разработки. Это позволяет нам упорядочить производственный процесс и сделать его более контролируемым. С другой стороны, есть подвижный список требований, управление изменениями, что свойственно гибкой методологии.



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



Проблемы долгостроя



1. Большое количество требований, конечный список которых изначально не утверждён

С одной стороны, увеличив сроки реализации, можно увеличить и количество требований, включаемых в версию. Немного цифр: в краткосрочный (в среднем, полугодовой цикл) релиз мы выпускали порядка 35 фич в версии, в последней версии с долгосрочным периодом пока заявлено около 100. При этом за 10 лет в базе требований было зафиксировано без малого 1600 потенциальных фич, которые заказчики ожидают увидеть в продукте, и список запланированного на ближайшую версию постепенно растёт. Закономерный вопрос: до каких пор это будет продолжаться?



2. Определение приоритетов и оценки

Решение вопроса, озвученного в предыдущем пункте – в расстановке приоритетов среди отобранных владельцем продукта требований с учетом полученных оценок (разработки, тестирования, документирования и рисков), которые делаются на основании предоставленной аналитиком спецификации. В каждой компании свои подходы к расстановке приоритетов. Это может быть изучение статистики запроса о реализации той или иной фичи, результаты конкурентного анализа, партнёрские обязательства, да и здравый смысл никто не отменял. Мы регулярно проводим опросы среди заказчиков и партнёров, стараемся получить максимум информации извне (например, у нас открыт портал «Идеи и предложения», где каждый может оставить заявку или проголосовать за уже существующие предложения). Способами получения информации являются также семинары, вебинары и другие общественные мероприятия. На основании всех полученных данных устанавливаются приоритеты, но они могут меняться, за этим приходится следить в реальном времени. В нашей практике наибольшее влияние на позицию фичи в списке требований оказывает критичность её для проектов и общая востребованность: прежде необходимое, потом уже желаемое. Повышению приоритета может способствовать общий эффект от реализации функциональности – речь о wow/killer фичах.

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


3. Общее и частное







Эта проблема впервые возникает в любом продукте на момент формирования списка требований, независимо от периода его реализации. В отличие от проектного решения, где движение идёт от общего к частному, в продукте всё наоборот. Мы получаем извне отдельные пожелания, при этом заказчики описывают зачастую каждый свою специфическую задачу, и пожеланий по схожей теме может быть несколько. Ключевая задача — свести и учесть их все в конкретном требовании. Но проблема может возникнуть и повторно, и за тот период, что разрабатывается версия (здравствуй, долгострой), заинтересованные стороны могут предлагать новые решения или уточнять нюансы. Порой приходится вносить коррективы с учётом этих предложений в виде запросов на изменение, что может вызвать в итоге сдвиг точки Stop Development. Не всегда получается свести это просто к записи «1601-го пожелания к развитию системы».



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

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


4. Проблема айсбергов







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



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

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


5. «Тяжёлые» фичи: делить или не делить?

В долгосрочном проекте мы можем позволить себе реализовать не только относительно простые требования, но и более сложные фичи, одна разработка которых требует от 80 часов. Как правило, для каждой такой доработки необходимо подробное и объёмное ТЗ, множество тест-кейсов и т.д. Тут и возникает необходимость разделения требования на несколько частей, ведь воспринимать меньший объём информации проще. Но, во-первых, при разделении требования теряется «картина в целом». Во-вторых, увеличивается общее количество требований к версии, что сказывается на эффективности контроля, оценке и управлении изменениями. В нашем случае, если разделить озвученные выше 100 фич, мы получим приблизительно трёхкратное увеличение количества требований. Безусловно, это не повод для отказа от разделения определенных требований на составляющие. Делить стоит, но там, где это действительно необходимо: например, при наличии независимых доработок в рамках одной фичи, скажем, в ситуации, когда сценарий общий, но для его реализации требуется реализация новой функциональности в разных частях системы.



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

Пример, когда требование можно разделить.

Первоначальное требование: «Поддержать интеграцию с Microsoft Lync 2013 в контролах карточек с возможностью сохранения истории диалогов».

После разделения: «Поддержать интеграцию с Microsoft Lync 2013 в контролах карточек» и «Реализовать возможность сохранения истории диалогов Microsoft Lync 2013 в карточке».



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

«Необходимо сделать отображение по разрядам в контролах Число и Целое. Например, вместо 1230000 показывать 1 230 000. По возможности сделать такие же доработки и для Таблицы».


Релиз близко



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



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



Анна Курманова, бизнес-аналитик Docsvision.

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

http://habrahabr.ru/post/265559/

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

[Из песочницы] Здравый смысл важнее алгоритмического мастерства

Четверг, 23 Июля 2015 г. 20:19 (ссылка)

Предлагаю читателям «Хабрахабра» перевод небольшой заметки «Organizational Skills Beat Algorithmic Wizardry» за авторством James Hague. Заметка показалась интересной и мне захотелось поделиться с аудиторией.



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



На самом деле большая часть работы программиста не требует такого алгоритмического мастерства.



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



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



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



И именно так выглядит большая часть разработки программного обеспечения.

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

http://habrahabr.ru/post/263427/

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

Как мы создали универсальную систему управления бизнесом

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

Предисловие



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



Будь то 1С, Битрикс, Мегаплан или тем более самостоятельные решения – они требуют установки специфического софта, налаживания удаленного доступа к серверу через VPN или другие решения, не работают с плохими каналами связи – какие часто встречаются в торговых центрах или удаленных офисах, и уж точно требуют недюженого умения работников для доступа из дома или командировки.



Отдельно можно сказать о производительности: для меня, как разработчика высоконагруженных систем БД, всегда было странным формирование отчетов не за секунды, а десятками минут, проведение документов занимающее в 1С минуты, и вообще постоянно требующие обновления железа новые версии тех же систем, с баснословными требованиями к серверам. Очевидно было, что такие простейшие операции как посчитать остатки на складе за весь период работы из миллиона документов даже в MySQL займут секунды…



Постановка вопроса



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



Хотелось следующего:

• Полностью удаленное пользование с любой операционной системы, с планшета, смартфона

• Нетребовательность к качеству канала связи

• Дружелюбный интерфейс и юзабилити

• Скорость – любые отчеты и документы в течение секунды

• Возможность встраивания продвинутой аналитики



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



Разработка



Мощностей на серверах хватало, поэтому за три вечера на первом бутстрапе, PHP и MySQL был создан опытный образец который умел вести номенклатуру, считать остатки на складах и имел простейшие документы первичной бухгалтерии с печатными формами.



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



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

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



Так что каждый раз, когда мы проводим документ, мы просто берем все остатки указанных в документе товаров, считаем их с нуля, и если все OK, то делаем саму операцию списания-зачисления. Как понятно, выборка по обычному количеству в 10-20 товаров из правильно структурированной таблицы даже из сотен тысяч строк – дело долей секунды. До сих пор даже на высоконагруженных применениях это работает отлично.



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



Все эти размышления, кстати, убили во мне всю последнюю веру в решения типа 1С. Если база данных устроена хотя бы просто «подходяще», то все данные по фирме можно пересчитывать в секунды. Подчеркиваю ВСЕ, и сразу одновременно. Чем занимается этот монстр при перепроведении документов или формировании отчетов вообще неясно. Даже сильно медленный PHP скрипт, без php-cgi, простая MySQL без оптимизации под конкретную БД и загруженная другими проектами под завязку обсчитывали складские остатки «с нуля», без промежуточных данных за 3 года работы в течение долей секунды.



Та же задача, на 1С, на той же фирме, за те же 3 года занимала 15-20 минут, хотя в базе было всего несколько тысяч документов по 5-10 товаров в каждом…

30 тысяч записей за 15 минут… Кому-то, наверное, это кажется быстрым.



Внедрение



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

Самое главное – любые отчеты формировались за доли секунды, и сидя в метро в другом городе или за рулем в машине я открывал отчет со смартфона с диагональю 3,5” (да, на тот момент это был нормальный экран) и видел все цифры по бизнесу, которые меня интересовали.



В результате получилась система, которая полностью находилась на наших серверах, имела бекап раз в два часа, продвинутый контроль доступа и логирование. Система была доступна через любой браузер с iPhone, смартфона или планшета под Android, работала под Opera, Firefox, Chrome одинаково. В практически неизменном виде она проработала несколько лет.



Мы могли открывать доступ к выбранным складам нашим отдельным контрагентам и дилерам, все необходимые бухгалтерские отчеты получать на лету, магазинам было достаточно дешевого 3G интернета, а главный бухгалтер выгружал данные одним кликом в свою версию 1С для своей работы.



image



Партнеры



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



Пропуская лирику, на перевод всех филиалов на нашу систему ушло меньше 3 месяцев вместе с обучением, импортированием данных, правами доступа и подстраиванием бизнес-модели. Годы были потрачены на разработку решений, которые не давали результата, месяцы на внедрение у нас вместе с разработкой аналитики специфической под конкретные задачи компании.

image

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



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



Сейчас система находится по адресу bmsys.org – там же можно прочитать про список возможностей и модулей работающих на данный момент.

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

http://habrahabr.ru/post/259541/

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

Сравнение техподдержки крупнейших производителей ПО в сфере сетевой безопасности

Понедельник, 13 Апреля 2015 г. 17:17 (ссылка)

Привет, Хабр! Откладываем ноуты в сторону – код никуда не убежит. Сегодня мы поговорим о самой страшной перспективе карьеры программиста, которая может заставить вздрогнуть даже бывалых прогульщиков IT-вузов и поспешно начать допиливать несданный код. Нет, вы не угадали, это не касса МакДоналдса, это техподдержка. О ней, любимой, и пойдёт сегодня речь.



Итак, это обзор. Точнее – обзор показателей доступности техподдержки, ещё точнее – техподдержки ключевых игроков рынка IT-продуктов в сфере сетевой безопасности и контроля нежелательного доступа.







А начнём мы именно с наших полевых экспериментов. Мы оценивали техническую поддержку компаний по таким параметрам как:




  • юзабилити контактов;

  • обучающие тексты и видеоуроки;

  • спектр средств связи с техподдержкой;

  • время ответа оператора;

  • поддержка пробной версии;

  • поддержка на форуме;

  • присутствие в соцсетях.



Мы призываем коллег к обратной связи и готовы предоставить этот блог для ответа.



Краткий обзор технической поддержки в разных IT-компаниях



UserGate




  • удобный поиск контактов: прямая ссылка в раздел из главного меню;

  • текстовые инструкции, FAQ (по ФСТЭК-версии) – предусмотрены;

  • связь с техподдержкой: e-mail / тикетная система;

  • время ответа оператора по e-mail: 6–14 часов;

  • удалённая поддержка, поддержка пользователей пробной версии – в наличии;

  • есть группы в соцсетях: Facebook и Twitter, обновляемые до трех раз в месяц.







Ideco




  • удобный поиск контактов, прямая ссылка в раздел с каждой страницы сайта;

  • текстовые инструкции в открытом доступе, записи вебинаров – после регистрации;

  • типы взаимодействия: форма обратной связи, e-mail, форум, вебинары, онлайн-консультант, ICQ, Skype, заказ звонка, бесплатная горячая линия;

  • в плане ответа оператора по электронной почте оказались шустрее предыдущего производителя: 2 часа;

  • удалённая поддержка: сервис встроен в программу;

  • поддержка пользователей пробной версии и поддержка на форуме – в наличии;

  • присутствуют в социальных сетях: ВКонтакте, Facebook, Twitter и Google+, с обновлением раз в 3 — 15 дней.







ИКС




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

  • есть текстовые инструкции, в т.ч. FAQ, и видеоуроки;

  • связь с техподдержкой: форма обратной связи, личный кабинет, e-mail, форум, онлайн-консультант, ICQ, Skype, телефон;

  • время ответа оператора по e-mail: 2 часа;

  • удалённая поддержка платная;

  • ответы на отправленные запросы по пробной версии к техподдержке не были получены;

  • присутствуют в соцсетях: ВКонтакте, Facebook, Twitter (посты раз в 1 — 5 дней).







Kerio




  • ссылки на контакты техподдержки найти легко;

  • есть англоязычные текстовые инструкции и FAQ;

  • после регистрации можно получить записи вебинаров;

  • связь с техподдержкой: форма обратной связи с обязательной регистрацией на сайте и телефон;

  • поддержка продукта бесплатная для владельцев действующей Software Maintenance и зарегистрированных юзеров trial-версий;

  • есть англоязычный форум;

  • в социальных медиа присутствуют на английском (в Facebook, Linkedin, Twitter), регулярные посты по будним дням.







GFI




  • удобный поиск контактов, прямая ссылка в раздел техподдержки;

  • есть англоязычныетекстовые инструкции и база знаний;

  • каналы коммуникации: форма обратной связи для зарегистрированных пользователей, телефон;

  • время ответа на e-mail оператору: 1,5 часа;

  • общение с техподдержкой только на английском языке;

  • поддержка, форум и группы в соцсетях — англоязычные, но достаточно живые.







Kaspersky




  • в шапке сайта есть удобная ссылка на раздел техподдержки;

  • есть текстовые инструкции, видео уроки в едином корпоративном стиле;

  • типы взаимодействия: форма обратной связи в личном кабинете, e-mail, форум, группы в соц. сетях, телефон;

  • время ответа оператора: 24 часа;

  • есть удалённая поддержка и поддержка пробной версии;

  • живо (новые посты несколько раз в день) присутствуют в соцсетях: ВКонтакте, Facebook, Twitter, YouTube, Мой МирMail, Одноклассники и Google+.







По итогам наших субъективных тестов, лучше всего техподдержка налажена у Kaspersky.



Именно их клиентам удобнее найти нужную информацию или получить обратную связь.



По нашему мнению, ключевые составляющие дружелюбного и хорошего сервиса это:




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

  • Инструкции. Многие стараются сами разобраться в проблеме. Больше гайдов, господа разработчики!

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



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



Техподдержка Смарт-Софт: внутренняя кухня



Придерживаясь традиции, для начала резюмируем информацию:




  • раздел техподдержки — в главном меню сайта;

  • подробнейший структурированный FAQ, 21 видеоурок на русском языке;

  • каналы связи с support: форма ОС на сайте, e-mail, форум, онлайн-чат JivoSite, skype и телефон;

  • время ответа оператора по телефону: 2 — 5 минут;

  • есть все виды поддержки: базовая и расширенная (но о них чуть ниже);

  • в соцсетях с нами можно связаться через паблик в ВКонтакте, страницу на Facebook, аккаунт в Twitter, канал на Youtube и группу Google+ — раз в 3 — 5 дней мы обязательно публикуем что-то интересное.







Рады сообщить, что через месяц мы представим обновленный дизайн нашего сайта, раздел саппорта в нем предстанет в таком виде:



Раздел контактов:







Раздел FAQ:







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



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



Как работает техподдержка Смарт-Софт



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



Обязательные требования:




  • высшее техническое образования в одном из ведущих государственных ВУЗов;

  • знание основ компьютерных сетей;

  • знание всей линейки ОС Windows на уровне администратора;

  • технический английский.



Дополнительные требования к соискателям:




  • сдать экзамен по программному продукту и основным настройкам Traffic Inspector, и ОС Windows комиссии технических специалистов;

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

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

  • уметь быстро решать типовые проблемы пользователей;

  • уверенно ориентироваться в консоли Traffic Inspector, отчётах, клиентском агенте и на портале;

  • хорошо знать функционал программы, особенности работы в различных режимах;

  • уметь устанавливать и настраивать Traffic Inspector на всех поддерживаемых ОС и при любых типах сетевых подключений;

  • знать все модули Traffic Inspector и уметь с ними работать.







В нашей компании у проявивших себя работников есть хорошие перспективы карьерного роста. Типичный пример: сотрудник пришел к нам в 2010 году на должность стажера технической поддержки со стартовой зарплатой в 10 000 рублей. За 5 лет работы в компании он прошел путь к успеху от стажёра через инженера технической поддержки, инженера-тестировщика до руководителя службы.



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



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



Большинство обращений пользователей в нашу техподдержку приходят через электронную почту (50% обращений), звонки по skype и IP-телефонии (40%), остальное приходит через онлайн-чат, соцсети и форум на нашем сайте. Служба технической поддержки работает по будням с 8:00 до 18:00 по Москве.



И, напоследок, время упоительных историй о трудовых буднях безымянных героев техподдержки Traffic Inspector:




  • Однажды к нам на линию позвонил пользователь и сходу начал описывать свою проблему при помощи весьма подозрительных терминов, явно отсутствующих в великом и могучем русском IT-языке. Мы весьма долго пытались с ним найти общий язык, но нить разговора постоянно ускользала. И вдруг внезапно пользователь сказал: «Подождите, я тут ещё грибочков поем и перезвоню». Бывает.

  • Девушка-оператор приняла обращение пользователя, поставила звонок на паузу и обратилась к нам, мол, что делать – у пользователя «клапан заблокирован»? Все впали в лёгкое недоумение, ибо даже лучшие умы отдела не смогли связать заблокированный клапан с работой сетевого экрана. Один из help desk коллег взял у нее трубку и попросил пользователя еще раз внимательно прочитать с экрана, какая конкретно у него выводится ошибка. И, что бы Вы думали, там было? Класс не зарегистрирован! С ним поделились забавными грибочками?

  • Позвонил пользователь, сказал, что у него проблемы с работой программы, нужные сайты блокирует Traffic Inspector. Мы начали выяснять настройки его программы, вроде бы всё было сделано правильно и сайты блокироваться не должны. Начали разбираться и решили для страховки переустановить программу. И тут пользователь выпалил: «Вообще-то, Traffic Inspector у меня не установлен, но это точно он во всем виноват». Коварная программа, коварная…



Вместо эпилога



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



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



Предыдущие посты:



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

http://habrahabr.ru/post/255623/

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

Следующие 30  »

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

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

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