Category: it

Category was added automatically. Read all entries about "it".

Превед

Себестоимость – это обман

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

Допустим, есть у вас программист. Хороший программист, работает много… скажем, часов 150 в месяц. Получает большую зарплату – 3000 долларов. Место в офисе занимает – метров 10 по 100 долларов в месяц за метр. Компьютеров и мебели амортизирует – особенно кресло амортизирует нещадно, потому что ест много. Пусть еще долларов 500.

Итого, стоит он вам 4500 долларов в месяц, или 30 долларов в час.

Приходит к вам клиент и просит написать ма-а-аленькую программку. На день работы, 8 часов. Программка плевая – там реально работы на час, потом еще час баги править, и еще 6 часов на всякое. И предлагает клиент за это 200 долларов. Причем торг, для простоты примера, здесь неуместен.

30 * 8 = 240. Это себестоимость работ. А предлагают вам за них всего 200 долларов.

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

Или нет?

Посмотрите внимательно на своего программиста. Что он сделал с высвободившимися 8 часами? Вполне может оказаться, что это время он потратил на прокрастинацию. Или на новый дизайн для сайта, которым пользуются только сеошные боты. Или на очередную доработку фреймворка. Ну, вы поняли. Вы только что потеряли 200 долларов.

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

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

Зарплаты и мебель не являются полностью переменными затратами. Взяли вы заказ или нет – вы все равно несете эти затраты. Поэтому, при прочих равных, не взяв заказ вы затраты все равно несете, а деньги за этот заказ теряете. И становитесь беднее на 200 долларов.

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

А с себестоимостью не сравнивайте. В вашем бизнесе себестоимости нет.

Originally published at meatreach.ru. You can comment here or there.

Превед

Управленческий учет для юзабилистов и программистов на Питоне

У вас уже готов бюджет вашего бизнеса на 2010 год?

Большинство бизнесов не делают годовых бюджетов. А если делают – то уж лучше бы не делали.

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

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

Мы не знаем, каким будет будущее.

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

Три главные идеи, которые помогут вам начать планировать свои деньги:

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

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

Хотите научиться?

Тренинг для ИТ-предпринимателей, которым нужно выстроить учет в своем бизнесе: Управленческий учет для юзабилистов и программистов на Питоне. Ориентировочная дата – 23 января 2010 года.

На тренинге речь пойдет не только о бюджетировании. Основные темы:

  • Бухгалтерский, налоговый и управленческий учет.
  • Система балансовых счетов, учет хозяйственных операций.
  • Как не терять компьютеры и запчасти – склад, учет и выдача материальных ценностей.
  • Где мои деньги?! Кто кому сколько должен.
  • Налоги. Как законно принимать Яндекс.Деньги.
  • Бюджетирование без вранья.

и многое другое.

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

Ведь деньги – кровеносная система вашего бизнеса.

Кстати о деньгах. Стоимость участия в тренинге 7500 рублей. Скидка для оплативших до 31 декабря: стоимость всего 2500 рублей. Для оплативших до 12 января включительно – 5000 рублей.

Тренинг будет, как всегда, проводиться только один раз.

Для записи на тренинг жмите сюда.

Originally published at meatreach.ru. You can comment here or there.

Превед

Услугоспособность

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

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

(no subject)

Итак, тренинг стартует в понедельник, 24 марта.

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

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

Мы будем рассказывать о том, что делаем сами, приходя к новому клиенту – и кое что из того, что не делаем, а надо бы. ;) Здесь не будет страшных слов типа CobiT, сложных методологий и соответствия многотомным стандартам – мы ориентируем этот тренинг на руководителей и специалистов малых и средних бизнесов и хотим сделать его максимально «близким к земле». Практика, практика, практика. Конкретные рекомендации и типичные ошибки.

Основные темы, о которых хочется поговорить:
  • Документирование инфраструктуры. Чтобы разобраться, нужно сначала узнать, что у вас вообще есть
  • Процессы. Основа ИТ – не железки и не программы, а процессы, которым следуют люди – как айтишники, так и все остальные сотрудники
  • Риски. Если вы не используете ИТ – вы рискуете отстать от конкурентов. Если вы используете ИТ – вы рискуете тем, что у вас что-нибудь сломается. Этими рисками нужно управлять.
  • Возможности. Знаете ли вы, какие возможности упускаете?
  • ИТ-стратегия. В конце немножко поговорим о том, зачем вам это все.

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

Все 20 бесплатных мест на тренинг уже заняты. Сейчас (для первых 20 платных участников) стоимость тренинга составляет 10000р. Для следующих 20 она составит уже 20000р., потом 40000 и т.д. Записи тренинга будут доступны всем участникам, остальные смогут их купить позже. Стоимость записей сразу после тренинга также составит 10000р., потом вырастет.

Оплата для юридических лиц – безналом (присылайте реквизиты, вам выставят счет, оформят договор на участие в консультационном семинаре и т.д.), НДС не облагается. Для физических лиц – в любом банке, или наличными в офисе. Можно также через WebMoney или Яндекс, если так удобнее.

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

Комменты с заявками скринятся.
Превед

(no subject)

Скрытые шары, которые Windows создает по умолчанию:
a. c$ (и другие диски, включая CDROMы), Admin$
b. c$ (и другие диски, включая CDROMы), Admin$, ipc$
c. c$ (и другие non-removable диски), Admin$, ipc$
d. c$ (и другие non-removable диски), Admin$, rpc$
Превед

(no subject)

Вам необходимо подключиться к SQL Server'у на компьютере в другом домене. Трастов между доменом, в котором находится ваш компьютер, и доменом, в котором находится SQL Server, нет. Вам известны логин и пароль пользователя, не являющегося локальным администратором на удаленном компьютере, но имеющего доступ к SQL Server'у. На удаленном компьютере нет ни одной расшаренной папки или принтера. Ваши действия:
a. net use \\remotecomputer\c$ /user:remotecomputer\nonadminuser
b. net use \\remotecomputer\sql$ /user:remotecomputer\nonadminuser
c. net use \\remotecomputer\ipc$ /user:remotecomputer\nonadminuser, затем запустить cliconfg, на вкладке Alias создать запись для remotecomputer с использованием протокола Named Pipes
d. net use \\remotecomputer\sql$ /user:remotecomputer\nonadminuser, затем запустить cliconfg, на вкладке Alias создать запись для remotecomputer с использованием протокола TCP/IP
Превед

(no subject)

Какой из протоколов аутентификации НЕ поддерживает Microsoft SQL Server?
a. SQL Server authentication
b. NTLM
c. Kerberos
d. Поддерживает все три
Превед

(no subject)

Про того, которого любила,
Про того, чьи письма берегла.


Katiusho Backup for Microsoft Exchange
Превед

Как заварить чашку чая?

Вот расскажите мне, как заварить чашку чая? По-простому, из пакетика.
Я задавал этот вопрос нескольким людям – со словами «дайте мне инструкцию, научите меня». Чаще всего это выглядело примерно так:
- Берем чашку, берем пакетик, кладем в чашку. Заливаем водой из чайника.
- А если в чайнике вода холодная?
- Ну, тогда сначала кипятим.
- А если там воды нет?
- Тогда наливаем, потом кипятим, потом заливаем. Но если ты хочешь, чтобы чай был правильный, то сначала надо, чтобы чашка была горячая...
Пошагово действуя по этой инструкции, я сначала залью пакетик холодной водой, потом сожгу чайник, включив его без воды, потом все-таки заварю чашку чая, и тут же узнаю, что чай получился неправильный и надо начинать сначала. А ведь задачка-то не такая уж и сложная.
Нормальный человек не способен сформулировать простой пошаговый алгоритм действия:
- Если в чайнике вообще нет или слишком мало воды, то налить ее
- Если вода в чайнике холодная, то вскипятить ее
- Если нет чистой чашки, то вымыть грязную
- Взять чистую чашку
- Налить полчашки горячей воды, дабы согрелась
- Положить в чашку пакетик, долить водой
- Ждать минуту, болтать пакетик
- Выкинуть пакетик
Большинство людей не обладают навыками алгоритмического мышления, до сих пор массово эти навыки есть только у программистов. Неспособность обычного человека сформулировать такую простую инструкцию была замечена довольно давно. Лет эдак много (20? 25?) назад Шеля Губерман и Лёня Кузнецов придумали язык программирования Либрал. В этом языке переменные можно было объявлять где угодно (в т.ч., после первого использования), исключительные ситуации (в чайнике нет воды) обрабатывать не до, а после их возникновения и т.п. – язык был расчитан на использование людьми, которые не могут разместить проверку исключительной ситуации перед основным действием, а сначала рассказывают самое главное. Я не знаю, в какой мере им удалось реализовать проект, продолжения у него не было, но многие из тогдашних идей уже давно реализованы в мейнстримовых языках – переменные объявлять вообще не обязательно, а обработку исключений (exception) действительно можно выкинуть в конец процедуры (try/catch блоки, On Error Goto и т.п.).
Либрал был хорошей идеей, но сейчас становится понятно, что двигаться-то надо, как раз, в противоположном направлении. Надо учить людей алгоритмическому мышлению, учить писать исполнимые инструкции и действовать по инструкциям, учить переключаться между разными типами мышления в зависимости от ситуации и текущих потребностей.
Сегодня в школах алгоритмическое мышление присутствует только на уроках информатики. Ни в математике, ни в физике его нет, там все происходит на «естественном» языке, всяческая теория автоматов и прочая алгоритмика в школьную математику не попадает. Но даже и на уроках информатики детей не учат алгоритмическому мышлению – их сразу учат программировать. 80% детей оказываются не в состоянии воспринять основные конструкции, необходимые для написания программ, поскольку алгоритмическим мышлением не владеют – они перестают воспринимать предмет с самого начала, происходит полное отторжение. Остальные 20% (а может и меньше, процентов 5-10) по каким-то причинам («врожденная» предрасположенность, случайность, родители, хороший учитель, в конце концов) схватывают базовый навык алгоритмического мышления (т.е., необходимость продумывать и обрабатывать исключения до, а не после), и дальше для них информатика оказывается чрезвычайно простой наукой. Но их – 5, 10, максимум 20%. В результате информатика оказывается маргинальным предметом, и алгоритмическое мышление вместе с ней. До сих пор подавляющее большинство детей, заканчивающих школы, не обладают базовыми навыками алгоритмического мышления, т.е. не способны сформулировать простейшую пошаговую инструкцию.
Вы думаете, эти навыки нужны только программистам? Почитайте законы. Почитайте нормативные акты, инструкции, почитайте какие-нибудь письма Минфина, описывающие правила, алгоритмы и методики ведения бухучета. Почитайте регламенты и правила в государственных органах и частных компаниях. Все эти документы написаны людьми, которые не очень сильны в обработке исключительных ситуаций. Послушайте, как какой-нибудь менеджер, бригадир или прораб объясняет своему сотруднику, что тот должен делать. А еще веселее – найдите менеджера, бригадира или прораба, способного сформулировать пошаговую инструкцию со всеми исключительными ситуациями, и посмотрите на его сотрудника, когда он будет пытаться воспринять эту инструкцию! Ведь навыка восприятия алгоритмов тоже нет.

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