Я думаю, большинство хабралюдей должно быть знакомо с такой вещью, как майндмэпы, они же карты разума, они же диаграммы связей. Для тех, кто не в курсе, поясню: майндмэп — это иерархическая диаграмма, отображающая множество взаимосвязанных мыслей.
У диаграмм связей существует много возможных применений. Например, с их помощью можно разрабатывать базы данных и абстрактные структуры классов, проводить мозговой штурм или планировать личные расходы. Расскажу, как я применяю их в учебе.
У меня, как и у многих других программистов, есть слабость: я очень люблю различные планерки, на которых обсуждаются новые проекты и идеи. Все презентации в моем представлении делятся на 3 вида: муторное чтение цифр успеваемости начальника транспортного цеха, демонстрации системы из рук и презентация идей и решений при помощи построителя презентаций. Если с демонстрацией системы из рук программисты знакомы по сдаче лабораторных в университетах, а монотонно читающие тексты «коты баюны», постепенно вымирают как класс, то с презентациями у нашего брата явный напряг. Менеджеры еще прошли либо просмотрели курсы «молодого построителя презентаций», то молодежь ограничилась книгами типа «Уроки ПоверПоинта за 24 часа» или хуже того, один раз увидели и самотыком изучили сей продукт буржуазной экономики. Поэтому, просмотр их презентаций вызывает приступ тошноты, не говоря уже о том, что их часто перебивают, вызывая на «живое» общение. Ориентироваться в их презентациях невозможно и зачастую бессмысленно. А ведь для того чтобы создавать красивые презентации нужно немного. Попробую составить список «наставлений для программистов», что делать нельзя и что нужно.
Как разговаривать с клиентами по телефону в интернет-магазине
После списка будут даны объяснения по каждому пункту.
Разговор с клиентом должен начинаться с «Здравствуйте, *название магазина*» (или что-то похожее). Никаких «алло», «да» и тд.
Искореняйте из разговоров менеджеров «слова паразиты». Речь должна быть чистой.
Ответы менеджера всегда должны быть уверенные и утвердительные. Особенно касается это вопросов с подковыркой со стороны клиента.
«Улыбайтесь» в трубку. Голос менеджера должен звучать бодро и весело. В аське сдержанно используйте смайлики типа «)», если клиент сам вставляет графические смайлы, можно использовать и их.
Повышайте компетентность менеджеров. Чем выше квалификация специалиста, тем качественные ответы для клиента, тем выше доверие клиента к вашей компании.
Никогда не перебивайте клиента. Дослушайте до конца, даже если вы уже знаете концовку вопроса.
Постарайтесь узнать, какие цели преследует клиент, покупая этот товар. Возможно, его выбор не соответствует поставленным целям, задача менеджера объяснить неверный выбор и дать компетентную консультацию.
Не позволяйте менеджеру долго расспрашивать клиента о контактной информации, рассказывать по телефону об акциях и скидках и остальную несущественную информацию.
Если необходимого товара нет, всегда предлагайте клиенту другие варианты.
Работайте в режиме «менеджер-клиент», а не «клиент-менеджер».
Если разговор зашел о том, что магазин будет связываться с клиентом через определенное время, четко определите это время.
Всегда перезванивайте клиенту, если произошли какие-либо существенные отклонения от договоренностей с клиентом.
Если у вас, что продается «мелкое» к товарам, стоящее небольшие деньги, проходит какая-то промо-акция с пробниками или каталогами, предложите клиенту купить «мелочь» или участие в промо-акции.
В конце разговора подталкивайте клиента к заказу фразами «на какое число оформлять доставку?», «Какой товар будете заказывать?»
Если запрашиваемый товар проходит по акции или имеет скидку — обязательно сообщать об этом.
Нельзя впихивать клиенту залежалый товар. Обман всегда становиться явным. Предлагайте клиенту товар, который бы посоветовали сами себе.
Сообщайте по телефону клиентам вместе с суммой заказа их скидку.
Нельзя использовать фразу: «это последние на складе» как прием для убеждения сделать покупку.
Если решили через менеджера узнавать, откуда пришел клиент, не будьте настойчивы. Максимум 2 вопроса.
Всегда благодарите клиента за оказанное вам доверие: «спасибо за заказ» или «спасибо за покупку».
В аське всегда в одном сообщении с информацией товара указывайте его цену.
Хочу рассказать вам о книге Тома Вуджека «Тренировка ума». Книга показалась мне достаточно интересной.
Эта книга — практическое пособие по тренировке мозга, умственных способностей.
Книга состоит из двенадцати глав. Каждая глава — это своего рода тренажер, предназначенный для развития определенного качества вашего ума. На одних тренажерах вы будете попеременно то прилагать усилия, то расслабляться, погружаясь в безмятежное спокойствие; на других вам придется муштровать свой ум «до седьмого пота». Одни упражнения предназначены для активации вашего левого полушария — аналитической, логической части мозга, другие — для правого полушария, интуитивной части мозга, также ответственной и за пространственное восприятие. А все вместе тренажеры обеспечат вам всестороннюю интеллектуальную тренировку.
Во время путешествий часто может пригодиться не только бумажная, но и интерактивная карта.
О Google Maps знают многие, но это не всегда работает. На помощь путешественнику придут следующие ресурсы из моей коллекции:
Очень часто приходилось слышать такое от людей, которые много времени проводят за администрированием и другими IT-забавами.
Я, за не очень долгий опыт реального администрирования пришел к обратному выводу. В консоли (командной строке) В Windows можно выполнять очень много разных операций, которые стандартными возможностями не выполняются или выполняются некорректно/неудобно/долго (нужное подчеркнуть)
Совсем недавно где-то на Хабре промелькнуло высказывание из серии «Не думал, что консоль в Виндах что-то может. Хотелось бы узнать об этом побольше».
Вот так и возникло желание написать небольшую статью про основные возможности консоли.
Несколько моих знакомых с гордым видом называют себя moneymaker-ы. Честно сказать меня они довольно сильно раздражают. Я проанализировал чем именно они меня раздражают и на основе этого посторался выделить общее в этих горе-бизнесменах.
В этой статье я расскажу об одном необычном подходе к генерации лабиринтов. Он основан на модели Амари́ нейронной активности коры головного мозга, являющейся непрерывным аналогом нейронных сетей. При определенных условиях она позволяет создавать красивые лабиринты очень сложной формы, подобные тому, что приведен на картинке.
Вас ждет много анализа и немного частных производных. Код прилагается.
Прошу под кат!
Решил поделиться методом обучения сего мощного, но в одно и тоже время лёгкого языка программирования. Он действительно лёгкий. Вам не надо будет запоминать и вводить лишних символов, которые Вы можете встретить в Си-подобных языках.
Удобочитаемый синтаксис, прост в обучении, высокоуровневый язык, Объектно-Ориентированый язык программирования (ООП), мощный, интерактивный режим, масса библиотек. Множество иных плюсов… И это всё в одном языке.
Для начала окунёмся в возможности и узнаем, что же умеет Python?
Эта статья содержит необходимый минимум тех вещей, которые просто необходимо знать о типизации, чтобы не называть динамическую типизацию злом, Lisp — бестиповым языком, а C — языком со строгой типизацией.
В полной версии находится подробное описание всех видов типизации, приправленное примерами кода, ссылками на популярные языки программирования и показательными картинками.
Рассмотрим ситуацию, когда необходимо обрабатывать столкновения между объектами. Как вы в этом случае поступите? Вероятно, самым простым решением будет проверить каждый объект с каждым другим объектом. И это правильное решение, и все будет замечательно до тех пор пока объектов не много. Как только их станет порядка нескольких тысяч, вы заметите, что все стало как-то медленно работать. А если частиц несколько десятков тысяч или сотен? Тогда все замрет. Вот здесь уже интересно, на какие хитрости и оптимизации вы пойдете, чтобы решить такую проблему.
Для простоты, будем рассматривать 2D случай, частицы круглые, радиус частиц у всех одинаковый.
Содержание
1. Обзор алгоритмов
1.1. Полный перебор
1.2. Sweep & Prune
1.3. Регулярная сеть
2. Некоторые оптимизации
2.1. Sweep & Prune
2.2. Регулярная сеть
3. Сравнение скорости выполнения
4. Приложение (программа и исходный код)
5. Заключение
В продолжение темы, начатой статьёй «13 причин не быть управленцем» и продолженной в «5 причин быть управленцем», хочу обратить внимание на такой аспект работы абстрактных «управленцев», как продукт их труда. Из своего опыта знаю, что недостаточное понимание этого аспекта свойственно как разработчикам, так и самим «управленцам». А где недостаточное понимание – там и конфликты, и холивары, и пренебрежительное отношение как к собственной работе, так и к работе коллег.
Какими свойствами должен обладать хороший тимлид? Он, несомненно, должен быть технарем, иметь разносторонний опыт, уметь налаживать диалог внутри команды и с начальством, вести дискуссии и принимать решения, брать на себя ответственность, понимать бизнес-процессы, думать как заказчик и владелец бизнеса. Ну и быть немного психологом.
В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.
В итоге часто получается как-то так:
Потому что на десять сеньоров по статистике девять тупят.
Меня просто бесит, когда менеджер проекта отправляет макет дизайна — письмом, с припиской «Вот, нарисовали. Смотрите. Ждем ваших замечаний». Убил бы.
Такой менеджер, по сути, ломает весь кайф. Он похож на официанта, который, вместо того, чтобы эффектно сорвать крышку с серебряного блюда и устроить обещанное fire-шоу, бесцеремонно грохает поднос на скатерть и бросает рядом спички. Типа, дальше сами разбирайтесь. А в глазах у него читается недвусмысленное: «Штоп вы подавились».
Резервное копирование базы данных — это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы — это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья — для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.
Согласно поговорке, программисты — это устройства, преобразующие кофеин в код.
Если спросить первого попавшегося программиста, когда он наиболее продуктивен, — скорее всего, он назовёт ночь. Кто-то пораньше, кто-то попозже. Популярен вариант встать в 4 утра и сделать работу до начала дневной суматохи. А некоторые предпочитают ложиться в 4 утра.
Цель всего этого — избавиться от отвлекающих факторов. Но можно было бы просто закрыть дверь… Что же такого особенного в ночи?
Я думаю, что всё сводится к трём вещам: расписанию творца, сонному мозгу, и яркому экрану компьютера.
Вопросы можно оставлять в комментариях, отправлять по электронной почте info@mlgconsult.ru или задавать через твиттер @mlgconsulting до 10 июля 2010 г. Вы можете задать любой вопрос о создании ИТ-бизнеса, авторских правах, привлечении инвестиций и любой другой вопрос из области ИТ-предпринимательства.
Ответы выйдут в качестве бесплатной брошюры и будут размещены на сайте юридической компании MLG Consulting и ресурсах Марины Деревянко. Помимо этого, будут даны комментарии к заданным в данном посте вопросам.