Поделюсь мыслями с руководителями отделов

Любая работа должна быть оплачена. Не стоит допускать с клиентом выполнения дополнительных работ "по-дружески".

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

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

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

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

Задания лучше выдавать по электронной почте, а сотруднику отчитываться о выполнении так же, а не устно. Устной формой стоит пользоваться, как дополнительной.

Все правила работы должны быть сразу оговорены. Сотрудник не должен додумывать или угадывать.

Рабочее место должно окупаться.

Делегируйте обязанности. Взяв на себя слишком много, можно не справиться.

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

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

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

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

Работу любого сотрудника нужно контролировать. Любую задачу нужно держать на контроле.

Команда только тогда будет работать продуктивно, когда удовлетворяет 5-ти критериям:
1. Стремление каждого сотрудника к общему результату. А не к своему собственному.
2. Требовательность каждого сотрудника к себе.
3. Требовательность каждого сотрудника к другим членам команды.
4. Взаимное доверие.
5. Наличие продуктивных конфликтов (обсуждений), которые приводят к результативным решениям. А не просто ругани и не уход от конфликтов.

...и с менеджерами по продажам

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

Если ваш продукт не будет решать проблемы клиента, продать его не получится. Только если это что-то совсем недорогое.

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

Различные приёмы закрытия сделки на крупных продажах не работают.

Быстро и прямо сейчас можно продать только что-то очень недорогое. Дорогие системы требуют нескольких встреч. Требуют вхождение в доверие к клиенту.

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

...и с начинающими веб-мастерами

Делайте сайты для людей, а не для поисковых машин. В долгосрочной перспективе это окупится с лихвой.

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

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

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

Сделайте доступность всей информации на сайте не далее, чем 3 клика от главной.

Обязательно для каждой страницы заполняйте тег <title> соответствующий информации на данной странице.

С помощью службы «Яндекс Блоги» ищите обсуждения по теме вашего сайта, вступайте в обсуждения, давайте ссылку на свой сайт.

Начальный трафик на ваш сайт помогут дать службы «Яндекс Директ» и «Гугл Эдвордс». Для интернет-магазинов хорошо себя оправдывает использование «Яндекс Маркет».

Подчёркивайте ссылки.

Не пишите тёмно-серый текст на светло-сером фоне. Ярко-оранжевый текст на кислотно-зелёном фоне - тоже не самое лучшее решение.

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

Идею дизайна можно подсмотреть здесь.

...и с аналитиками на разработке ПО

1. Для начала собираем пользовательские истории - как будущие пользователи с их точки зрения планируют использовать разработанное нами ПО.
2. Далее совместно с главным заказчиком ПО формулируем бизнес-цели. Вся дальнейшая работа будет вестись только в рамках (внутри) этих определённых бизнес-целей. При добавлении новой функции мы всегда будем сверяться, удовлетворяет ли она бизнес-цели.
3. На основе пользовательских историй составляем список функций, правил и ограничений будущего ПО.
4. Дополнительно описываем всё это различными блок-схемами. Чтобы было несколько представлений одной и той же информации для лучшего понимания.
5. При необходимости делаем прототип (демо-версию) будущего ПО. Прототип можно реализовать в виде нарисованных на бумаге или в редакторе экранов, демонстрирующих работу ПО.
6. Дополнительно прописываем нефункциональные требования (к безопасности, к производительности).
7. Четыре предыдущих пункта показываем фокус-группе пользователей, утверждаем документ.
8. Показываем тестировщикам, утверждаем документ.
9. Каждой функции назначаем приоритет.
10. На основе приоритетов составили итерации и план релизов. В первый релиз войдёт только несколько самых высокоприоритетных базовых функций.
11. Приступаем к разработке.


...и с системными аналитиками

- Цель системного анализа - провести улучшающее вмешательство в проблему.
- Улучшающее вмешательство - это такое воздействие на проблему, которое точно не приведёт к ухудшению позиции ни одного из участников проблемы (стейкхолдеров), но при этом приведёт улучшению позиции хотя бы одного участника (стейкхолдера).
- Проблема - это то, что вызывает недовольство у стейкхолдера.
- Недовольство можно устранить двумя путями - воздействуя на проблему или воздействуя на самого стейкхолдера.
- Существуют три варианта воздействия на стейкхолдера для избавления его от недовольства:
1. Сообщить ему дополнительную информацию, которой он возможно не располагает. И которая может помочь посмотреть на проблему с другой стороны.
2. Наоборот, утаить от него какую-то информацию. Или сообщить ложную информацию.
3. Попытаться прекратить взаимодействие стейкхолдера с проблемой.
- Для воздействия на саму проблему предварительно необходимо построить её модель.
- Для построения модели необходимо проанализировать и описать все входящие информационные и материальные потоки в проблему. И все исходящие информационные и материальные потоки из проблемы. Это стрелочки в наш и из нашего "ящика" проблемы.
- Далее для построения модели необходимо проанализировать и описать всех участников проблемы (стейкхолдеров).
- После построения модели, можно моделировать различные воздействия на систему, которые должны привести к улучшающему вмешательству.


...и с проектными менеджерами

- Руководителю проекту (далее - РП) нужны полномочия. Без полномочий проект не будет успешным.
- РП нужна команда на проект. Если на проект не назначены конкретные сотрудники-исполнители, то проект не будет успешным.
- Спонсор (куратор) проекта - лицо, которое осуществляет не только финансовую, но также любую административную или организационную поддержку проекта.
- Проект уточняется пошагово: от наиболее общей постановки задачи (цели) до конкретных пунктов плана проекта.
- Чем раньше делается изменение в проекте, тем дешевле оно обходится. Поэтому тщательная аналитика на старте проекта очень необходима.
- Любые изменения в проект вносятся через запрос на изменение. Все изменения фиксируются в журнале регистрации изменений.
- Проект всегда разбивается на этапы (фазы). Следующий этап (фаза) начинается только после окончания предыдущей фазы.
- Если предыдущую фазу не завершили, то проект закрываем. Kill point - ключевая точка проекта, на которой решаем, стоит ли продолжать проект дальше.
- Длительность проекта можно рассчитать методом критического пути, учитывая работы, которые можно выполнять параллельно.
- С большой долей вероятности проект потребует больше времени и средств, чем изначально предполагалось. Поэтому всегда должен быть резерв и времени, и средств.
- Качество нужно улучшать непрерывно. Причём как качество выпускаемых продуктов, так и качество ведения проектов.
- По итогу каждого завершённого проекта делаем выводы (lessons learned), что можно сделать лучше в следующий раз.

Итого, что нужно для работы по проекту:
1. Сбор требований по проекту со всех заинтересованных сторон.
2. Описание этапов проекта.
3. Формирование команды проекта (заказчик, спонсор, РП, исполнители)
4. Описание потенциальных рисков проекта.
5. Описание предполагаемых результатов и критериев приёмки.
6. Составление плана проекта с иерархической структурой работ, сроками по каждому этапу, исполнителем по каждому этапу и результатами работ по каждому этапу.


...и с менеджерами по ИТ-безопасности

- На каждый компьютер д.б. установлен антивирус.
- Выход в интернет д.б. через единый сервер, на который должен установлен сетевой экран (фаервол). На сетевом экране должны быть закрыты все порты, кроме непосредственно используемых. Например, закрыты все, кроме 80-го.
- Всё ПО для обеспечения безопасности (в т.ч. антивирус и фаервол) д.б. коммерческие, а не бесплатные. И должны регулярно обновляться.
- На все операционные системы нужно также регулярно ставить выпускаемые обновления.
- Все пользователи на своих компьютерах должны работы по учётными записями без прав администратора. Т.е. под текущими правами пользователя не должно быть возможности устанавливать какое-либо ПО.
- Пароли на компьютер и почтовый ящик должны удовлетворять требованию сложности: не менее 8-ти символов, в пароле должны присутствовать верхний и нижний регистр, цифры и буквы, спецсимволы (!,@,#,$ и т.д.).
- Административные пароли должны быть не менее 15-ти символов, в пароле должны присутствовать верхний и нижний регистр, цифры и буквы, спецсимволы (!,@,#,$ и т.д.).
- Все пароли должны меняться не реже 1 раза в месяц.
- Авторизация по паролю можно заменить на авторизацию по физическому ключу с сертификатом ЭЦП, либо на авторизацию по отпечатку пальца или сетчатке глаза.
- При вставании с рабочего места каждый сотрудник обязан выйти из своей учётной записи так, чтобы повторный вход потребовал авторизации. Это и другие правила должны регулироваться политиками безопасности.
- При уходе с рабочего места должен оставаться стол без бумаг и записок.
- Каждый сотрудник должен иметь доступ только к той информации, которая ему необходима по работе.
- Должен быть установлен контроль за всем мусором (бумаги и любые иные носители информации), выбрасываемым организацией. По-хорошему весь подобный мусор должен уничтожаться внутри организации.
- Сотрудники, работающие с критической информацией, должны работать в экранированных помещениях, исключающих излучение компьютеров и мониторов во внешнюю среду.
- Всё компьютерное "железо" должно быть предварительно исследовано сотрудниками безопасности на предмет подслушивающих устройств.
- Со всеми сотрудниками должно быть заключено соглашение о неразглашении коммерческой информации.
- Для настройки обмена файлами с внешними серверами (организациями) необходимо использовать шифрованное соединение. Например, шифрованный канал SFTP внутри VPN-туннеля IPSec.
- Хранить информацию на серверах, например, пароли, также нужно в шифрованном виде.



Наброски на должность ИТ Директора

Жизненный цикл ИТ-услуги:
1. У всех сотрудников компании должно быть общее понимание стратегии развития компании. А также понимание необходимости каждой услуги по-отдельности.
2. Каждая услуга должна быть окупаемой и с приемлемым уровнем риска.
3. До начала оказания услуги проводится её исследование, описываются бизнес-требования, вносятся данные в каталог услуг.
4. При описании будущей услуги должны быть учтены требования по безопасности. В т.ч. описаны все требуемые политики.
5. Должны быть учтены требуемые серверные мощности для поддержания каждой услуги.
6. С внешними поставщиками услуг и с получателями нашей услуги (c юр. лицами) должны быть заключены соглашения об уровне сервиса (SLA). Непосредственно с исполнителями (с физ. лицами) должны заключены соглашения об уровне операционного обслуживания (OLA).
7. Под новую услугу создаётся проектная группа: руководитель, аналитик, тестировщик, программист. На основании бизнес-требований пишется устав проекта (руководителем) и спецификация на разработку (аналитиком). Согласовывается план проект со сроками.
8. Перед началом разработки подготавливается тестовая среда для разработчиков и тестировщиков. Отдельно пре-продуктивная среда, которая является аналогом продуктивной, но без бизнес-пользователей, на пре-проде проводится чистовая отладка кода. И продуктивная среду, куда непосредственно выкладывается релиз и которую непосредственно используют клиенты.
9. На основании функциональной спецификации и по плану проекта разработчиком пишется программный код новой услуги. Тестировщик его тестирует. Аналитик консультирует их обоих по вопросу, как новая услуга должна работать с точки зрения будущих пользователей, руководитель следит за сроками исполнения, при необходимости привлекает дополнительные ресурсы.
10. Когда у тестировщика и аналитика больше нет замечаний относительно новой разработки, принимается решение о выпуске релиза.
11. Аналитик пишет клиентские инструкции. Тестировщик перепроверяет инструкции за аналитиком.
12. Перед выпуском релиза создаётся комитет по изменениям (CAB), куда должны входить все ключевые сотрудники компании. Руководитель проекта новой услуги посылает запрос на изменение (RFC) в этот комитет с описанием новой услуги, рисков изменения, необходимости изменения и описанием, что из изменения было протестировано. Комитет по изменениям утверждает выпуск релиза.
13. Проводится оповещение пользователей. Релиз из пре-продуктивной среды переносится на продуктивную.
14. Далее должны быть найдены от 1 до 3 клиентов и запущен пилотный проект.
15. После завершения пилотного проекта и окончательного устранения всех замечаний программный код новой услуги должен быть перенесён в библиотеку образцового ПО.
16. Далее проект передаётся на поддержку в клиентский отдел для массового подключения к ней клиентов и в техническую поддержку для мониторинга.
17. Техническая поддержка совместно с аналитиком составляет план мониторинга на новую услугу.
18. Вся остальная документация по услуге также передаётся в отдел тех. поддержки для решения большинства возникающих проблем их силами.
19. При возникновении ошибок по новой услуге, запрос фиксируется клиенткой поддержкой и передаётся на техническую поддержку. При невозможности решения проблемы силами тех. поддержки, запрос должен быть эскалирован на аналитика и программиста, разрабатывавшего услугу.

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