Месяц: Август 2015

I’m at Вятский Дворик in Москва

https://www.swarmapp.com/r_aliev/checkin/55d067af498e5fcd0f867cd6?s=XCRULFKe_0Qj7ooCHebdnbKaOgo&ref=fb&source=openGraph&fbdevmode=true&appsflyerId=fbshare

Как сделать почти бесплатную корпоративную почту на неограниченное число сотрудников?

Моё мнение:

1. Для каждого сотрудника регистрируется ящик на gmail вида fio.companyname@gmail.com

2. В компании поднимается мейл-сервер на базе недорогой виртуалки. SMTP, MX records. Тут нужен админ, денег в месяц – не больше пары десятков баксов в месяц.

Для каждого ящика fio@companyname.ru настраивается безусловная пересылка (redirect) на fio.companyname@gmail.com

3. В настройках gmail настраивается from/ reply-to адрес на fio@companyname.ru. гугл потребует подтверждения по ссылке из письма.

В итоге, все хлопоты по поддержке сторейдж-серверов на гугле и бесплатны. Почта уходит с корпоративного адреса. Не знаю, работает ли такая схема с Индексом и Мейлом?

P.S. Если что – у нас не так.

Интересно, что Gillette на нашем рынке является почти монополистом – ближайший конкурент, Schick, рынка в России почти не имеет (1.5% против 60%). BIC с не одноразовыми бритвами я за конкурента жилетту не считаю, а больше никого нет.

Интересно, почему так? Причём расходники у Gillette нехило дорогие, за 20% ниже цену покупатели бритв легко попробовали что-то ещё. Неужели нет качественных китайских или европейских брендов, которые можно прокачивать в России?

Маша на рипстике, и я на лонге ловлю кадр, в парке Горького только что

Еще одно наблюдение за годы работы над софтверными проектами, особенно – e-commerce.

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

Бизнес сейчас таков, что если за, скажем, четыре месяца не запустил новый продукт (сайт, магазин или что-то еще), то объем изменений за это время накапливается такой, что еще чуть-чуть и правильнее надо будет все выбрасывать и делать заново. Разумеется, на это никто не идет, и система обрастает заплатками.

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

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

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

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

Поэтому для е-commerce-проектов я верю в компактные команды, выделенные на 100%, состоящие только из профессионалов-универсалов, способных в короткое время сделать революционные изменения, запустить, а уж потом можно передавать в спокойную поддержку.

Кстати, мы ищем разработчика (Java/Spring), QA, бизнес-аналитика и системного инженера. Рекомендуйте, у нас хорошо.

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

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

Пакетами работ являются мероприятия по достижению измеримых результатов – тех же фич, или макетов дизайна или документов или обучения или внедрения. Если делать оценку каждой фичи, то по уму нужно собирать в ней трудозатраты из всего жизненного цикла проекта – от проектирования архитектуры, интерфейса, разработки, прилаживания этого интерфейса до внедрения в live. Такое можно сделать, но как побочный продукт IMHO-нормальной оценки по фазам и пакетам работ.

Уфф. Вырвалось.

Лизе 14 лет (@ Hooters in Moscow)

https://www.swarmapp.com/r_aliev/checkin/55c8de15498eed44b26b04ff?s=iP0EIawoJD84DXlSm0uDmGslVbk&ref=fb&source=openGraph&fbdevmode=true&appsflyerId=fbshare

Ровно четыре года назад, директор издательского дома, в котором я работал 16-17 лет назад, Игорь Садомский, сорвался в трещину на перевале Шести в Северной Осетии (http://taganok.ru/forum/index.php?topic=973.0) .

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

К сожалению, Игорю тогда не повезло и он не выбрался. Светлая ему память. А фильм посмотрите, он того стоит, особенно тем, кто любит горы.

@[100001040248794:2048:Оксана Сницерева] @[814653289:2048:Anton Matorin] @[100002267003981:2048:Svyat Kulikov]

http://www.kinopoisk.ru/film/63670/