Month: August 2015

Very

I’m at Vyatskiy Dvoryk in Moscow

How to set up almost free corporate email for an unlimited number of employees?

My opinion:

1. Register a gmail box for each employee in the format fio.companyname@gmail.com

2. Set up a mail server in the company using an inexpensive virtual machine. SMTP, MX records. This requires an admin, and it shouldn’t cost more than a few tens of dollars a month.

For each box fio@companyname.ru, set up an unconditional forwarding (redirect) to fio.companyname@gmail.com

3. In the gmail settings, configure the from/reply-to address as fio@companyname.ru. Google will require confirmation via a link from an email.

As a result, all the hassle of maintaining storage servers on Google is free. The mail is sent from the corporate address. I wonder if this scheme works with Yandex and Mail.ru?

P.S. Just to clarify, it’s not like this with us.

Interestingly, Gillette has almost a monopoly in our market – its nearest competitor, Schick, barely holds any market share in Russia (1.5% compared to 60%). I don’t consider BIC with its non-disposable razors a competitor to Gillette, and there’s hardly anyone else.

I wonder why that is? Especially since Gillette’s consumables are quite expensive, buyers of razors could easily try something else for 20% less. Aren’t there any quality Chinese or European brands that could be promoted in Russia?

[:)] “…In the Russian language, at an unknown time and under unknown circumstances, the meanings of the words for icicle and lollipop were swapped. It should be lollipops hanging from the roofs, and children should be sucking on icicles!…” [LOL]

Masha on a ripstick, and I’m catching a shot on a longboard, just now in Gorky Park

On the longboard (@ Gorky Park in Moscow)

Another observation from years of working on software projects, particularly e-commerce.

The biggest risk to a project is the dragging of deadlines. As a consequence – the budget. It doesn’t matter whose initiative it is – the client’s or the developer’s. If the deadlines are slipping – the risk increases every day that the project will never be completed at all, the money won’t be received, the client will remain unsatisfied, etc. After a certain point, both sides lose interest.

Business is such that if, say, you haven’t launched a new product (website, store, or something else) in four months, the volume of changes over that time accumulates to the point where you might as well throw everything out and start over. Of course, nobody goes for this, and the system gets patched up.

Moreover – the longer the project, the more likely it is that the client will change their mind, that key people on the client’s side will change, that the market situation will change, and in our country, anything can happen. Therefore, everything must be done quickly.

The second problem is that when a project is stalled (no matter the reason – the client is slow in providing data or the developer is falling behind), the costs of labor continue to eat into the project budget. If the development company, in an effort to economize, reduces the resources allocated to the project (by switching someone to another project), it leads to a loss of interest and motivation in the team to finish everything on time and to do it well.

But how to fit a large project into a small timeframe? Here many make a big mistake – they create an excessively large team. Pushing resources should only be done to pull a project out of a mire, but not in its normal planning. A large team increases the number of communications within the project, which in turn increases the volume of documentation and the contradictions and ambiguities that permeate this documentation.

Therefore, we try to make everything very compact and try not to inflate the team without a very great need. Unfortunately, to achieve this goal, it is sometimes necessary to mix some roles that should be separate in the team for large projects. But if you separate them, then the problem of increasing the number of communications arises, and as a result, the increase in timelines and budget. And the growth of timelines – see point 1.

Therefore, for e-commerce projects, I believe in compact teams, dedicated 100%, consisting only of versatile professionals capable of making revolutionary changes in a short time, launching, and then it can be transferred to calm support.

By the way, we are looking for a developer (Java/Spring), QA, business analyst, and systems engineer. Recommend them, we have a good team.

The most foolish way to estimate the labor involved in a software development project is by assessing individual features. Almost for every project, one has to fill out tables for the client like “feature – labor estimate”. It would be fine if these features were actual work packages that are more or less independent. Frequently, one encounters non-functional requirements, quality requirements, performance, and interface requirements. Estimating how many working days are needed to meet, for example, quality requirements or performance requirements separately from other functional requirements is a thankless task.

IMHO the only correct method for estimation is to break it down into phases and work packages with measurable outcomes and to estimate by work packages. In this case, a feature might be the result of work from different packages. Quality requirements and other non-functional requirements are merely constraints.

Work packages are activities aimed at achieving measurable outcomes – be it features, design mockups, documents, training, or implementation. If one were to estimate each feature, logically, one should collate the labor from the entire project lifecycle – from designing the architecture, the interface, development, fine-tuning this interface to going live. This can be done, but as a byproduct of what I consider, IMHO, a normal estimation by phases and work packages.

Phew. Just had to get that out.

Arbor Fish GT 39″ + Stella 69mm 78a abec-5