У меня и у нескольких рецензентов этой статьи ушло довольно много времени на то, чтобы ее подготовить. А люблю писать код и очень не люблю писать тексты. Поэтому мне ооочень не хочется писать вторую часть, где я обещал описать организацию работы команды.
Буду очень признателен, если вы припомните среди этого шлака и подкинете мне хорошую практическую статью в формате риск — как сделать правило/неправильно — цена ошибки. Я тогда дам ссылку на нее вместо обещанного продолжения.
Что же касается опыта, то у меня есть опыт создания только одной маленькой dream team, которая 1.5 года в отличном темпе выдавала качественный продукт, а потом в одночасье прекратила существовать из-за нескольких описанных в этой статье ошибок.
А после майских праздников в этом году попросту выключился, бросив на произвол судьбы своих пользователей, и продукт, который мы делали. Это тоже результат описанных выше ошибок и один из основных поводов к написанию статьи.
Представьте себе человека, который состоялся и заработал деньги, скажем, в ресторанном бизнесе. А там заметно другие подходы к подбору и мотивации персонала. Это тоже сложная задача (поэтому рестораны так различаются по качеству обслуживания) и он умеет ее решать.
А теперь у этого человека есть идея сделать программный продукт. Только он не просто не читал этих учебников, он совершенно уверен, что ему их читать не нужно, он же умеет управлять персоналом! И вот он нанимает команду, вкладывает деньги, забирает с рынка специалистов и… всё это тратится с нулевым выхлопом. В процессе страдает основатель, страдает команда.
Цель, которую я ставил перед собой — не открыть миру новое знание, а изложить самые базовые моменты так, чтобы они были понятны человеку без опыта в индустрии, и при этом не вызывали совсем уж яростной критики тех, кто в теме.
Упоминаемый в статье Брукс актуален уже несколько десятилетий. Но почему-то каждый год я вижу новые и новые повторения одних тех же ошибок со все теми же печальными последствиями. Ну не читали люди, у которых есть идея и деньги, но которые раньше к разработке не имели отношения, ни Деминга, ни Брукса.
Весь смысл этой длинной статьи в том, чтобы на абсолютно реальных и довольно болезненных примерах обратить внимание то, что к работе с командой нужно подходить ответственно. И теорию — изучать.
Последнее утверждение неверно. Ключевым (и уникальным) свойством урана является не пирофорность (это уже «заброневой» эффект), а особые физические свойства материала в момент пробития. Хорошо описано в этой статье в «Популярной механике», например.
Елена, сервис классный, каждому B2B сервису, где работа с контрагентами важна, стоило бы его заинтегрировать для удобства пользователей. Но вот он у вас, кажется, уже больше года в бете, это грустно.
К сожалению, я пока еще нигде не обновился до Win10, чтобы посмотреть, как Kilo будет там работать. Боюсь, новая версия появится именно по этому поводу.
Если там будут какие-нибудь интересные проблемы (и их удастся решить), напишу еще одну статью. А если нет, то просто отпишусь здесь в комментариях.
Неожиданно… Вроде, не было там таких зависимостей. И не должно быть. Спасибо большое, посмотрю. Заодно я как раз научился цвет меню пуск и экрана блокировки менять, надо будет впилить)
А в IE 11 нестабильно работает отрисовка флага в полях ввода на странице и не перехватывается смена языка. При этом в Kilo смена языка перехватывается.
Разница в том, что в режиме Advanced положение каретки не забирается из GetGUIThreadInfo, а через Accessibility по ищется по OBJID_CARET. В этом случае отображение языка возле каретки корретно работает в Visual Studio. Но все равно не работает в IE 11, к сожалению.
Не нашел больше никого из пользователей с такими симптомами. Если есть Visual Studio, то наверное самое лучшее — запустить под отладчиком и посмотреть, что происходит.
Буду очень признателен, если вы припомните среди этого шлака и подкинете мне хорошую практическую статью в формате риск — как сделать правило/неправильно — цена ошибки. Я тогда дам ссылку на нее вместо обещанного продолжения.
Что же касается опыта, то у меня есть опыт создания только одной маленькой dream team, которая 1.5 года в отличном темпе выдавала качественный продукт, а потом в одночасье прекратила существовать из-за нескольких описанных в этой статье ошибок.
А после майских праздников в этом году попросту выключился, бросив на произвол судьбы своих пользователей, и продукт, который мы делали. Это тоже результат описанных выше ошибок и один из основных поводов к написанию статьи.
А теперь у этого человека есть идея сделать программный продукт. Только он не просто не читал этих учебников, он совершенно уверен, что ему их читать не нужно, он же умеет управлять персоналом! И вот он нанимает команду, вкладывает деньги, забирает с рынка специалистов и… всё это тратится с нулевым выхлопом. В процессе страдает основатель, страдает команда.
Цель, которую я ставил перед собой — не открыть миру новое знание, а изложить самые базовые моменты так, чтобы они были понятны человеку без опыта в индустрии, и при этом не вызывали совсем уж яростной критики тех, кто в теме.
Весь смысл этой длинной статьи в том, чтобы на абсолютно реальных и довольно болезненных примерах обратить внимание то, что к работе с командой нужно подходить ответственно. И теорию — изучать.
Постараюсь в длинные выходные раскурить дестяку, но на 100% обещать не могу! :)
А инструкция по интеграции вот тут: www.nalog.ru/rn66/service/egrip2/egrip_vzayim
Если там будут какие-нибудь интересные проблемы (и их удастся решить), напишу еще одну статью. А если нет, то просто отпишусь здесь в комментариях.
Разница в том, что в режиме Advanced положение каретки не забирается из GetGUIThreadInfo, а через Accessibility по ищется по OBJID_CARET. В этом случае отображение языка возле каретки корретно работает в Visual Studio. Но все равно не работает в IE 11, к сожалению.